By Sourabh Suri
Whether or not an application should be bug free is hardly a topic of debate. Depending on the kind and severity, bugs have the potential to massively impact the working of an application leading to system failure, customer dissatisfaction and loss of revenue.
And since no software can be completely bug-free, what is important to focus on is the accepted threshold. Bugs often are the only portions of the application that we want to weed out. At times, developers may even be fine with gold plating, scope creep and other unnecessary features. However, bugs remain simply unacceptable.
In my opinion, no known bug should exist in an application. That is because even a bug that you may consider small or harmless can cost you a lot. Here’s why.
Bugs are difficult to identify and fix once committed
This is one scenario most development engineers can relate to. The code check-ins are never streamlined and clean in the source code repository as in the picture above on the top left. Once the code check-ins start piling up on each other, the code looks more like the picture on the right and it becomes difficult to identify the problematic code and even more difficult to take out and fix it.
Bugs Breed more Bugs
The relevance of this statement wouldn’t diminish, even if we were to borrow it from a chapter in biology and apply it to software development. If a certain piece of code is faulty, it will lead to more errors just to keep the rest of the logic compatible with the faulty code. And the moment you fix the root bug, the rest of the bugs will pop up. And now, you’ve got more bugs to fix.
I generally tell this to my team: Bugs have unusual powers. They can turn your code into touch- me-nots.
Intention vs reality
Talk to engineers and they will say in unison that they only intend to create the right codes. But, if only good intentions were enough, no error would have occurred in the first place. There would have been no need of bug tracking systems either.
Engineers intend to code right, for which they need help – a tool or an aid that can point out when they are going wrong, where they are going wrong and point out how to correct it. Without the right tools, the source code itself becomes a breeding ground for bugs.
It is established that bugs at point need to be avoided, or better, prevented. Can this be achieved only by manual testing or peer reviews? Certainly not.
Manual Testing cannot catch all errors: Imagine a product has more than ten thousand messages that occur with some permutation and combination of various configurations and various scenarios. Do you think manual testing alone can verify all of them?
Manual reviews are prone to misses and delays: Today, engineering teams in the industry follow a process of Peer Review. But manual reviews are prone to delays and slips.
Impossible to eyeball the entire source code: It’s humanly impossible to identify violations in the entire source code just by eyeballing.
Cost of Bug Fixing:
The later a bug is found, the more expensive the fix is likely to be. Research shows that a bug that could have been fixed with an x amount of resources at the time of coding itself, can take as much as 30 times the effort and money, if fixed later. In the later stages, it may also involve more stakeholders in addressing a bug.
These situations point towards the need for a system, or a tool that can prevent the issues from getting committed in the first place.
For instance, we have implemented what we call the “Continuous Code Inspection”. This system has a static code analysis (SCA) tool integrated at various stages of the software development lifecycle such as:
Coding: Integrating the tool with the IDE gives a capability to highlight violations during coding itself.
Peer Review: Integrating the tool with pull request or peer reviewing tools such as Review Board helps the reviewer of the code to identify the violations.
Build: Integrating the tool with the build stage ensures that the build fails if any of the violations are detected in the code. This can work for specific kinds of problems that don’t have any room for negotiation.
Code Submit: If the code is submitted and still carries any violation, a bug is raised in the bug tracking system to track that violation. The bug can be closed once it is resolved or it is identified that the violation is not a bug and it is there in the code by design.
Benefits of Continnuous Code Inspection- Continuous Code Inspection not only prevents issues, but also helps us in other manners.
Nipping the Bug in the Bud- The probable violation is nipped at the very moment it takes place and hence doesn’t let the effect of the violation grow.
Bug Tracking- If any issue somehow makes its place into the code, the issue is raised in a bug tracking system and treated as any other bug in the release. No issue/violation escapes unnoticed and hence, there is no unknown issue in the code.
Governance through Metrics- The system generates a lot of data and metrics that helps us keep the technical debt in control and tailor trainings by pointing towards the i18n concepts. This also helps us in communicating the globalization health of various products in various platforms.
We have piloted this solution to address globalization related issues. However, it has been found equally effective in preventing other coding related issues such as secure coding. The system is centrally controlled, and this allows it to seamlessly integrate with any new product, just like plug and play.
(The author is a Sr. Engineering Manager and Strategist at NetApp)
