A few years ago, a company I worked for was suffering from quality problems. We were expanding into new areas, pushing the product in new directions, and releasing new features quickly. As we pushed out new and evolved products, quality declined. Everything came to a head when customers began openly complaining about software quality. Our CTO stepped in with a mandate to solve the quality problem. His approach? The Zero Bug Policy — no-one was allowed to work on new features until the number of bugs in the product backlog was zero.
What is the Zero Bug Policy?
A Zero Bug Policy is simple. All bugs take priority over all new feature development or improvements. That’s it. There is nothing more.
An important corollary of this approach is that there is no such thing as bug priority, critical bugs, or minor bugs. 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.
Why is it Effective?
Despite (or maybe because of) its simplicity, a Zero Bug Policy is very effective at increasing product quality. Why? It avoids having teams become desensitized to bugs, and therefore desensitized to the user experience. As we let bugs build up, and let the quality of the product deteriorate, bug reports become the new normal. Expectations of quality become skewed so that a “good week” is one with less than ten new bugs reported, rather than the typical twenty-five.
By not treating bugs as high priority issues, we normalize bad behaviour.
In addition to resetting a team’s expectations of quality and user experience, a Zero Bug Policy includes a number of ancillary benefits.
Reduced Development Costs
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. You may be fixing somebody else’s code, and that person may be on vacation. You end up in an unfamiliar place in the code which requires you to debug, address, and validate a fix with a slow and meticulous approach, building up knowledge and context step-by-step.
Better Estimates
Bugs, by their nature, are unpredictable — it is extremely difficult 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 even understand the cause of the bug, let alone implement a fix. A bug-free codebase removes this uncertainty, making it easier to predict how long new feature development will take.
If all that’s left is new code, then your schedule will be stunningly more accurate.
Increased Agility
By keeping a bug free codebase, you can ship your product to customers, with high quality, at all times. This allows you to react quickly to changing market conditions. If you absolutely need to get a feature in for a customer demo, you can implement and ship just that feature, without having to fix any number of accumulated bugs. This increased agility goes hand-in-hand with the ability to produce better estimates. If we’ve removed the uncertainty of bug fixing from software development, we’ve suddenly increased our ability to ship meaningful features and improvements in shorter time spans, increasing overall agility.
Increased Customer Satisfaction
Most importantly, treating bugs as high priority means we treat customers and their experience as high priority. We avoid subjecting our customers to painfully incomplete user experiences, and keep customer’s faith in our product and our company high. Whereas each individual bug may not seem like a big deal, the accumulation of many bugs over time erodes the trust that customers put in us, leading to the proverbial death by a thousand cuts.
How to Start Today
A key value proposition of a Zero Bug Policy is its simplicity. It takes almost nothing to start! Begin by going through your existing issues and correctly classifying bugs. Move any bugs to the top of the backlog for the development team to start working on. The development team must not start working on any other items in the backlog until all bugs are cleared. NO EXCEPTIONS! If this rule is compromised, the technique will not work. It is this rule that forces product managers and development teams to correctly prioritize bugs over new work.
It may be impossible to continuously produce bug-free, production ready code. Bugs will always exist, yet getting to a state of zero known bugs is absolutely possible. Good software teams can be distinguished from great software teams by their approach to bugs. You can choose to be great.