The Whys And Hows Of A Zero Bug Policy
Many companies have adopted a zero bug policy (ZBP) and seem to be happy with it. Should you follow it too? And how would you do that? Let’s find out together.
Why fix bugs immediately?
For some, this may be a silly question. But since we can decide not to fix a bug at all, we should be aware of the consequences.
When users detect a problem with a brand new feature, then the developers will still be familiar with the code. In theory, the root cause should be easier to find and the bug quicker to fix.
Every bug can cause customer requests, which puts a burden on support and increase their cost. And customer satisfaction might decrease.
Having a low number of bugs in the backlog makes planning easier and our performance more predictive.
Why not fix bugs?
In short, because the effort of fixing a bug is higher than the expected value.
Imagine a problem that only occurs under rare circumstances and affects a small number of users. If it takes days to fix it or even forces you to change your solution, it may not be worth it.
Another reason is that you are about to reimplement or replace the associated feature. And if we experience too many problems with that feature, we should do that in any case.
One last reason is that we do not have enough resources. Now, this seems counter-intuitive at first. After all, the ZBP tells us not to start anything new if we have bugs. But we might be in the rare situation that we have to meet an externally imposed deadline, e.g., an existing provider will stop their service, and we need a replacement.
Fix it now or delete it
At its core, a ZBP means that we should strive to have no bugs in our backlog. That does not suggest our product is bug-free (which is hard to prove anyway), nor does it require us to fix every bug.
A ZBP forces us to decide: Fix the bug immediately (definitely not later than the next sprint, provided sprints are short) or delete it.
As stated above, there are valid reasons not to deal with a bug right now. However, if it gets into the backlog, the chances are high that we will never fix it. Hence, delete it.
To avoid any misunderstandings: Some products, such as software for airplanes, infrastructure, or even APIs, may not allow any bugs. In that case, a ZBP should equal to fix it now most of the time.
Dealing with your legacy
You may have a considerable number of bugs already in the backlog. The best way to deal with them is — you may have guessed it — fix them now or delete them.
You can start by applying the ZBP only to new bugs, but you eventually need to get rid of the old ones. My recommendation is to go through the latest and most critical bugs only and delete the rest. Some of them will probably be already obsolete.
Don’t fix bugs. Solve problems.
ZBP can be regarded as a variation of Zero Defects, which goes back to Philip B. Crosby. Conversely, other key figures in quality management, such as William Edwards Deming, criticized that idea. Why is that?
Crosby’s main concern has been sloppy workers and management that tolerates a minimum number of defects because zero defects are impossible. Deming, on the other hand, focused on the system. He did not believe in putting the burden on the workers.
If a company does not have testers, use tools for code analysis, and developers do not write automated tests, then a ZBP will not get you anywhere. If, however, the measures mentioned before are in place, and a bug occurs, then we should ask ourselves how this could happen.
If our goal is to improve quality, we should identify the conditions that need to exist so that that bug will not slip through. Maybe we think through too few scenarios, or the requirements are not clear enough, or our tests are not reliable enough.
When we take a look at all the bugs, we will identify clusters. Some areas of the application will have more defects than others. Certain types of bugs will appear more often. If we want to improve our product’s overall quality, we will target these clusters rather than individual bugs.
Conclusion
A zero bug policy can be beneficial if you apply it relentlessly. But it’s not a silver bullet for quality. It’s best not even regard it from a quality perspective but see it as a tool to manage bugs.
Bugs are just symptoms. If you want to improve your product’s quality, you need to improve every aspect of the system: The processes, the skills, the tools, the design, and much more.
