No Bugs Allowed
The Zero Bug Policy establishes a scheme to reduce the number of bugs users report directly or indirectly. It removes bug management and makes every single failure in the system have the highest priority.
The Zero Bug Policy moves a team’s output towards quality.
The effectiveness of the Zero Bug Policy
The policy establishes that new feature requests need to wait until no bugs exist in the system.
A Zero Bug Policy is simple. All bugs take priority over all new feature development or improvements.¹
Its execution is as simple as going through the bugs list and either fixing it now or deleting it. Make any incoming new bug a high priority so the entire team can work on resolving the issue.
Begin by going through your current issues and correctly classifying bugs. Move any bugs to the top of the backlog for the development team to start working on.¹
The beauty of this technique is its simplicity. However, the policy is only effective when applied fully.
The development team must not begin working on other items in the backlog until all bugs are cleared. NO EXCEPTIONS! If this rule is compromised, the technique will not work.¹
The accumulation of bugs decrease product quality
Postponing bug resolution reduces the required context developers need to identify and fix the root cause. The policy removes the uncertainty that bugs create for a development team.
The unpredictable nature of bugs creates an environment in which the whole system becomes uncertain, which will end up affecting the team’s velocity and accuracy in the medium to long term.
Bugs, by their nature, are unpredictable — it is complicated to predict how long it would take to fix a bug and how much impact fixing a bug will have on a product’s release schedule.¹
Fixing a bug could take two minutes, or it could take four days to understand its cause, let alone implement a fix.
A bug-free codebase removes this uncertainty, making it easier to predict how long new feature development will take.
Treat all bugs as critical
All bugs are critical problems that affect the quality of the provided service. The important result of treating every bug as high-priority is the elimination of bug management.
Every single bug becomes critical to the stable operation of the whole system. There is no such thing as a bug priority.
An issue is either a bug, or it isn’t. And if it is a bug, you need to fix it before doing other work.
Ignoring even a single bug could lead several customers to a bad experience.
Development teams that constantly update a system are at a higher risk of allowing bugs to creep through customers’ experiences. The problem with the accumulation of bugs while at the same time delivering more features comes in the form of a lack of predictability for future development and lower quality of service.
Bugs tend to become obsolete pretty quickly in applications that are updated frequently. The steps to reproduce become irrelevant, the functionality changes, the impact of the bug often get lowe¹
Zero bugs leading to high-quality systems is a value proposition that will benefit customers and teams.
When there are no visible bugs in a system, every single new feature adds value to customers.
By keeping a bug-free codebase, you can ship your product to customers, with high quality, at all times.¹
If you need to get a feature in a fora customer demo, you can implement and ship just that feature without fixing any number of accumulated bugs. No bugs mean increased agility which indirectly improves the ability to produce better estimates.
The accumulation of bugs leads to mistrust from customers. Each bug may not seem like a big deal, the proliferation of many bugs erodes the trust customers put in the company. The reduction of bugs allows the team to react quickly to changing market conditions.
The process is simple, and it doesn’t require any change in the team’s development strategy.
The idea is to resolve any incoming bugs as soon as those bugs show up.
Debugging issues usually happen in a production environment. Instead of focusing on previous bugs without real-time context for debugging is easier to remove every bug older than a week.
The majority of the rest of the bugs are already live. They have been in your bug tracking system/on your wall for a while. Delete those. If the bug is still valid, it will get reported again. Don’t waste time going through lists of potentially obsolete bugs. If you’re using a bug tracking system, find all bugs created before you release them and delete those.¹
Waiting too long to resolve a bug increase the complexity to understand the problem and have a smooth debugging session.
If a bug is reported and you wait two months to address it, by the time you follow up, you’ll probably have forgotten about that piece of code and need to re-learn the issue, the context surrounding it, and the implementation.²
[¹]: [[blog.crisp.se]] (2021): *Stop Managing Bugs, Start Focusing on Quality! — Crisp’s Blog* (https://blog.crisp.se/2018/02/05/yassalsundman/stop-managing-bugs-start-focusing-on-quality)
[²]: [[sookocheff.com]] (2021): *The Zero Bug Policy* (https://sookocheff.com/post/process/zero-bug-policy/)
