Last week i had some spare time which used in creating a tool to parse JUNIT reports and produce automated reports. This was done to do away with the stupid recurring responsibility which the team members used to get every once in a while, to baby-sit some JAVA project builds .
However since this was a pet project and done on my personal time, i could not get any QA time on this or afford to spend the normal time i would spend in creating the code normally. Not with the new Agile process and the accompanying rally tool used to measure all my tasks. So i did a real quick job out it and ended making some parts sloppy and corrected a few not yet encountered bugs, which i had to rework, since after all i could not afford to have such a sloppy tool lying around with my name on it.
It was then that i thought i should perhaps list down the origins of the bug which i saw in the code, along with the other common ones i have seen over the years in different code bases. So here they are, without much ado.
- An unfinished running list of “things to do” like cleanups / code smells, which introduces an unmanageable level of code debt.
- Heavy refactoring, which moves code around, which changes post and preconditions for the code copied, which is not handled or ignored in its new area – this was the new one for me.
- Lack of adequate error checks
- Not performing required cleanup when you exit a function or block
- Performing multiple things at a time WHILE coding (2 code-bases / support calls/ emails / calls / meetings …etc)
Bugs produced from this category of reasons are the most common and perhaps the most easiest to sense early, from a casual read of the code. For the same reason therefore, it is totally irresponsible of a team or its management if code which smells of the above manages to get released.
The next category of bug origins, would lie on a higher level and are more difficult to address and cannot be found from glancing the code and would typically require good code checking tools like lint or good reviews.
- Incomplete information about the API being used (eg free has to be combined with malloc and not new)
- Logical mistakes in the program flow
Seriously though, any programmer worth their salt, would have learned enough of their tools and would have passed enough theoretical exams, to make the above two points, extremely rare in the real world. It is here that the importance of the ‘frivolous’ reasons, increases in significance. In all my programming career, the most bugs i have seen are due to initial set of 5 reasons, which makes it all the more important to eliminate those.
It is also true, that only if the first set is eliminated, will the second become more obvious in code reviews, which is another reason why the initial set MUST be caught and corrected. The majority of the cost of a programming project, which is incurred after the coding is done, (80/20) over its support cycle, is also perhaps a good reason why these frivolous yet frequent bugs must be rooted out of the code base.
The remaining 3 reasons which complete our top 10 would be
- Platform complexity (custom Operating Systems, rare databases / applications, messy legacy code etc)
- Architectural mess
- Missing or wrong or Incomplete Requirement
Of-course the last few are issues that cannot be easily corrected once inherited and one can but put up with the mess and keep chugging along, managers and programmers included. In such conditions it is obvious that one need not add to the woes by creating more bugs and unwelcome noise on top of an already complex platform.
Therefore by all means and for gods sake create CLEAN code the first time !!!.