Implement a zero-bug policy

Katie Blackmore

Product development teams typically don’t use their own software enough to understand their customers’ experience, and underestimate how much their customers hate bugs. Meanwhile, many software development teams fix some bugs, but not others, and end up tracking hundreds of open bugs. This wastes time, and does not deliver value.

The Joel Test addressed this twenty years ago with this question:

5. Do you fix bugs before writing new code?

Spolsky explains that a team with a large number of open bugs has a worse problem than the time wasted managing that list: unknown liability for future work. Software development schedules have no meaning with open bugs. Fixing bugs first creates predictability.

Alternatively, save yourself some time by skipping both Spolsky’s article and this one, and immediately implement Yassal Sundman’s bug management system: Fix It Now or Delete It!

Adopt a zero-bug policy

Fixing bugs before you write new code means adopting a zero-bug policy:

1. When you discover a bug, fix it before other product development work, by default.
2. If fixing the bug delivers little value, discard the bug report instead.
3. Don’t keep low-priority bugs unfixed for ‘later’.

Anything else encourages releasing unfinished work and success theatre. Keeping bugs for ‘later’ also leads to double-handling, such as (repeatedly) reprioritising to even lower, rescheduling to even later, and reproducing buggy behaviour.

A zero-bug policy has an unexpected consequence at the start: you have to discard all bug reports that you won’t resolve before resuming other work. If this sounds extreme, consider that it won’t result in fixing fewer bugs.

Decide what to fix

Introducing a zero-bug policy does not mean fixing every bug: product managers have to decide what to ignore. Otherwise, you’ll incur the opportunity cost of fixing issues that don’t affect customers. Meanwhile, some bug reports describe improvements to existing functionality, or missing features.

Further reading:

• Stop Managing Bugs, Start Focusing on Quality! and The Definitive Bug Management System, by Yassal Sundman, advocate deleting bug reports.
• Zero-Bug Software Development, by Sam Hatoum, discusses reclassifying bugs as improvements or new features.

Choosing what to classify as a bug shouldn’t require discussion. If product managers and developers don’t agree on what to call a bug, you probably need to address other problems.

Continue discovering bugs

People who expect a zero bug policy to mean software that never has bugs clearly don’t understand software development. Don’t get upset by the zero-bug name, or confuse it with zero defects in industrial production; consider zero bugs as an achievable objective. Call it the zero bugs objective if you like.

You will continue to discover bugs, but you can have zero known bugs most of the time. If you don’t regularly achieve bug inbox zero, you have other problems, such as ineffective testing or unmaintainable code that slows down bug fixing.

Increase development speed

Zero-bug policies don’t only improve software quality. Avoiding managing bugs and having meetings about unpredictable development schedules gives you more time for product development.

Further reading:

• How a zero-bug policy doubled our development velocity, by Jan Peratt, explains how ‘fixing bugs continuously increases long-term velocity’.