If you think I am talking about the formula for making a successful film, then this is not your post. However, if you are looking for those elusive answers to bring some predictability to avoid boiler-plate bugs, then read on.
Boiler plate bugs? What’s that you say! You must have heard of routine code which developers need to write – the necessary evil – for all the configurations, the setup and bindings. Basically repeatable, no-brainer, energy-draining-code that most developers run from and shun from doing (hence the popularity of framework driven development).
Similarly, there are boiler plate bugs. These are those bugs which are, yes you guessed it, repeatable, no-brainer, energy draining and something that would have you or the QA bang your head in frustration and say “Duuhh! how many times will we make the same mistakes! What a waste of time!”
So here is a list of my favorite, such anger inducing bugs (caused as much by bad habits as by limited thinking), that can be easily avoided by RDBAT – Responsible Developer Behavior and Testing.
The Screen of Death – Yes, twitter may have come up with a whale, but every time you show the user a blank screen, it’s a screen of death. How do you feel when you open the contacts page of a new account and see a nice message that says ‘Hey, no numbers, care to add?’ vs, you guessed it, nothing!. So take care and give your users a nice little ‘Nothing here’ message and link them to next step. It adds the human touch, does not leave an internet novice wondering and it won’t come back to bite you in the form of a ‘user experience bug’.
My Text Runneth Over – This is one of my favorite pet peeves. While developing we tend to fill data that ‘fits well’ with the UI prototype. So when the client puts in real data, they go ‘Hey, it looks horrible, the text is all over the place.’ Most screens are about showing information. So why not test if the data fits or what would happen if you get more than expected! It doesn’t take much to do the text wrapping or trimming. As long as you remember it!
Gagged, Not Bound – This one is dedicated to those ArrayOutofBound exceptions that want you to gag whoever was careless enough to leave them! If you were playing baseball or cricket, overstepping the boundary is great. But in the development world it reeks of a grave oversight and irresponsible code. Whether displaying a list or a map, make sure you code for and test for 0 and/or key and the size, specially if the framework is not doing it.
The Communication Gap – This one isn’t so frequent, but it does tend to come up. I am talking about those exceptions where the web app sends a data whose size is more than what the database provided for! Like I said, it’s infrequent, now with most of us providing more on the data source and less on the front end. Still, it would be good to either remove the discrepancies or just limit the size on the web app.
Reuse With Care – Ever had an experience where the custom pop-up was working great in the booking module, but it broke for personal information? If you’ve worked on reusable UI components, then you know what I mean. Re-usability (one way to ensure DRY principle) is great, it’s a law of Development, specially in object oriented languages. But there are certain challenges on the UI side of life, such as in java-script and jQuery functions. Most IDEs would not be able to tell where it is being referenced (also true for interpreted languages). So you would not know if a change in the common function broke something in the another screen. It’s best to first check yourself all the modules that use it and only then dive into make the change. After that, don’t forget to test both the pieces. Otherwise, your testing team would be hard-pressed to find them (specially if they’re doing only manual testing) and it would ‘pop-out’ in the most embarrassing way in a demo.
CBR a.k.a Cross Browser Responsibility – When was the last time you were in a project when the QA or the client didn’t come back and say ‘Hey, it’s not working in IE 8/Chrome/Firefox’? We all have our favorite browsers and tend to develop only for those few but that’s not the scope. So before you even get down to building an awesome user experience or developing some really cool jQuery plugin that would revolutionize the way people would interact with the said app, stop and see if it is supported on the browsers you have committed to. Infact, start from the lowest version. If you’ve already developed or fixed a problem, go and test it on a different browser. ‘Leave it to QA’ did you say? Remember what they say about prevention is better than cure!
Whose Line Is It Anyway – You’ve finished your code, pulled the latest from the source repository, merged yours and pushed out. ‘Great, my work here is done,’ you would say! Nope… not so fast buddy. Before you pushed out the code, did you check the deployment? Did you run the test cases? Did you see if your code broke the build by any chance? Again, one may argue that there are build servers specially for that. But we’ve seen that a small check on the dev side can save the entire team so many hours to debug ‘whose line is it anyway’ that broke the build! Until you don’t run those test cases, don’t run the application to see if it’s working and your unit is up as expected; till then my friend, your job is far from over.
Its famously said ‘Quality is never an accident; it is always the result of intelligent effort.’ So it doesn’t require super human powers to become awesome. Just a little bit of intelligent effort and just a little more willingness to do so.