Everyone hates bugs, these nasty errors in functionality or code that make our customers unhappy, bugs that interrupt us in the middle of the night or weekend because something is not working as it should for the customer, or even less severe bugs that slow us down when we are developing new features.

Most organizations I know, treat bugs as something natural. Bugs happen.
Completely refraining from having them is usually considered very expensive or not “cost-effective”.
Well, I disagree. Bugs can be exterminated in a non-expensive \ cost-effective manner. How?

By using zero bug policy:

“Zero bug policy” means that we do not accumulate bugs. Whenever we find a bug we have three options:

  1. Fix it immediately.
    This is the easy option and should be the default choice, when someone encounters a bug, no matter who found it, who caused it, and when was it planted the code, we fix it. As simple as that. If we feel that fixing it is not a valid option right now due to the effort it requires for example, we need to try option 2.
  2. Declare and treat it as a known limitation.
    This is not as good as fixing it, but it is sometimes an option, for example The system was tested with 10M users and crashed. Not good news, but supporting 10M users may require a lot of work, and even more so, We currently do not have any customer that comes even close to 10M users, so a valid option here would be to declare that our system supports up to 2M users, but that is not enough, we may want to programmatically make sure that more than 2M users cannot be created and we shall implement the functionality needed to display an error to the user if he will try to create the 2,000,001 users. From this stage we may or may not go to option 3.
  3. Create a feature out of it.
    We decide that we do need to support 10M users, and we realize that we cannot treat it like a regular bug, so we shall treat it as a feature, we will add a requirement to our backlog, estimate it and prioritize it like any other feature.

Sound simple right? That’s because it is!

Some objections to this way of working is commonly heard:

  • We cannot immediately fix it, this is why we have the hardening period, so that bugs accumulate and we will fix them all at once and not stop to fix every tiny thing.
    While that may work for some, the cost of fixing a bug increases over time, fixing a bug that had just entered the code is relatively easy and quick, we remember what the code looks like, what is the business logic and other stuff that we will probably need to re-learn if we fix this bug later. Even more than that, if we fix it now we can save the trouble of opening a bug report or ticket.
  • Letting the team decides which bugs to fix is not a good idea:
    Yes, it is. It gives the team the opportunity to take pride in their work and produce high quality product (which is what they want to do), also in case they decide that it is not a good idea to fix it now they will need to get approval from the PO in order to create a feature out of it.
  • Wouldn’t that allow to simply “bomb” the backlog with bugs?
    It might, but when it does, it should be highly visible that our bugs are a cause for not being able to meet the deadlines, this is good! We want to know where we are all the time and not be surprised 2 weeks before we are supposed to ship the product.
  • Isn’t there a danger that the team and PO will simply declare many bugs as limitations?
    Yes there is, but this will also quickly become very visible that we are declaring more and more limitations on our products, not to say that this is a good or a bad idea, but this will raise important questions that we will need to answer.

And if you are not yet convinced that this is a good option let see some more advantages this practice has:

  1. There is no need for an internal bug tracking system, and by not having such a system you can save money (That you can use to make the team out for a fancy dinner for example).
  2. It simplifies the process – If you have no bugs, you do not need to constantly deal with bugs, prioritize them, declare never-ending lists of severity and priority. You can forget about bug metrics and triage meetings.
  3. You create and nurture a high-quality culture that will make your customers happy and create a better reputation for you, which will allow getting better and bigger deals and customers. This might come as a surprise, but this culture will also improve the satisfaction level of your employees.

So, what are you waiting for? Start your zero bug policy TODAY.
May the force be with you.

Share on print
Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on email