Zero-Bug Software Development

The Zero-Bug Policy is not a myth — it is the answer. And it can work for your team, today.

Perhaps one of the simplest process decisions that a software development team needs to make is also the most controversial: “What is our procedure for dealing with bugs?”

Is it really practical to aspire to have a Zero-Bug policy? And is that even desirable?

With the benefit of significant experience in this area, I can tell you that not only is a Zero-Bug policy absolutely achievable for your team, it is also easier to achieve than you may think.

However, let me start by setting the record straight:

Zero-Bug does not mean bug-free code production; it means striving to eradicate all known bugs.

It is impossible for developers to continuously produce bug-free, production ready code. Bugs will always exist. This article is about getting to a state of zero known bugs and that is absolutely possible.

A Case in Point

I recall working at the BBC about 10 years ago in London. I had just joined as an Agile coach, and I spent the first 2 weeks closely observing the 22-person team dynamics and following the work from start to finish.

The team was unable to achieve stability in their sprint velocity. Having looked back at their history, I could see that in some sprints they would deliver a high number of story points, and in other sprints they would deliver no points at all.

I observed the team constantly dealing with “small issues” at the expense of valuable work. The product owners and stakeholders were frustrated that they were not seeing the features they asked for, and fingers were being pointed in all directions.