As software developers, dealing with bugs and support tickets is a fundamental part of the job. It can often grow with the scale of the software or organization. The more users you have, the more bugs you will likely have to deal with. In the modern world of subscriptions where users can leave you more easily, providing a good support experience is critical.

Unfortunately, many software teams struggle with these aspects of the job. Bugs are often reported more quickly than developers can fix them and are deprioritized in favor of other “more important” work. Before you realize it, bug backlogs can become intimidating.

Not all bugs are created equal

When new bugs are reported, they are typically triaged and assigned a priority depending on their impact on end users. For instance, a bug preventing a proportion of users from accessing key functionality in your product is obviously of a far higher priority than a tiny graphical glitch causing something to not be quite aligned as expected. However, teams are often guilty of triaging too many tickets as high priority. This leads to these bugs sitting in a backlog and waiting weeks or sometimes months to be fixed. This begs the question - “were they really high priority?”

The software engineer and entrepreneur David Heinemeier Hansson summarizes this issue very well (click through for video).

All software has bugs. Many of them will never be fixed. This is normal, this is good. https://t.co/vSpxXdg0XC pic.twitter.com/uQIfzY4rlP

— DHH (@dhh) August 10, 2023

The Zero Bug Policy

In a nutshell, the zero-bug policy (ZBP) is a no-nonsense bug management system that can be summarized as follows:

If a bug is reported that you feel is important enough to fix, then you fix it right away. If not, you close it.

As part of this, having a clear and concise triage process is very important. This varies from team to team and product to product, but some common things to consider are:

• Is the bug on the red route through the product?
• Is the bug a regression?
• Is the bug part of core functionality and stopping customers from receiving value?

Advantages

There are several benefits to the ZBP. The first is an increased level of transparency with your users. For instance, teams often accept a bug and stick it on their backlog telling the customer “we will get to it as soon as we can”, knowing full well they will likely not look at it again for 6 months and then close it. In effect, they are lying to their customers, giving them false hope of a bug fix that was never going to come. Does that really feel right?

Another big benefit is a massive reduction in administration costs. By only keeping the bugs that are important enough to fix, managing a bug backlog becomes straightforward.

The final big benefit is a drastic reduction in the time taken to actually fix bugs and ship them to customers. By having few bugs in the backlog, actually prioritizing them for fixing takes less time, rather than waiting weeks or even months to get to that point.

Disadvantages

There are also a couple of potential disadvantages. Firstly, you might think that customers would get angry when you choose to not fix the bug they reported. However, in my experience, they are more often than not very understanding and simply appreciate the transparency. Just make sure you give a suitable explanation as to why you are choosing not to fix the bug!

Another potential issue is that prioritizing bugs above everything else can cause important feature work or operational maintenance to be continually pushed back. One option here - if you are working in 2 week iterations, for example - is to add bugs as a top priority in your next sprint, rather than putting them at the top of the to-do list in the middle of a sprint. This can help achieve a happy balance between fixing important bugs while still delivering key value to users.

Summary

The Zero Bug Policy is a really simple but effective bug management technique that helps you deliver important fixes quickly to your users. As with anything in agile software development, it's important to retrospect and iterate to make sure things work best for your situation, but I hope this article gives a good introduction.