Most software developers that have been around for a while are familiar with the Joel test. Some companies like to show off with a maximum score (12) on this test to attract high profile developers. A lot of best practices that are included in the scoring system are commonplace in the organisations that I've worked for, but I'd like to take a look at item number five.
5: Do you fix bugs before writing new code?
I've never worked somewhere where this question could be answered with "yes", so I'd like to make this practice top of mind again.
First, let us get a misconception out of the way. The name of this policy is a bit misleading, as writing bug-free code is a myth. Where there is code, there are bugs, no discussion about it.
The policy aims to have zero bugs on your backlog. While doing research on this topic, a couple of different implementations of this policy popped up, but they all share this common goal of a zero bug backlog.
The differences between adaptations are in how to achieve this zero backlog:
- Always fix the bug;
- Inbox zero style, decide whether:
- it needs to be fixed. Pick up directly;
- it won't be fixed, Close directly;
Do note that bug triage needs to be taken very serious. Often enhancements or originally missing requirements can be brought in as bugs, but make sure to validate it and relabel those issues, to avoid working on bugs that aren't really bugs.
The companies that have embraced the zero bug policy (see sources below), take the inbox zero approach: once a bug comes in, you must decide directly what to do with this: fix or don't fix.
If it is too trivial, or just simply not worth the cost, it is closed as a won't fix, so you never have to look at it again.
If it must be picked up, there are usually only two different types of issues: ones that require immediate attention, which means drop whatever you are doing. Otherwise, fix directly after you've completed your current task.
By forcing a product to have no known open bugs, a couple of practices are automatically in place, and considerable waste can be removed from the development process.
Anytime a bug comes in, it immediately requires resolution. An important benefit is that the possible reproduction scenarios, and the person logging the issue are probably quite easy to find, making it way easier to fix this issue. Fresh bugs often also relate to recent changes, so it is easier to backtrack where this issue was introduced. Of course there can be other reasons why new bugs emerge, but it really helps to start on them directly. I'm sure many developers have dealt with an issue that was over an year old. Trying to reproduce it or asking questions about context is basically out of the window, as the original reporter has no clue about it anymore or might even be gone from the company. Maybe the troublesome feature has been rewritten in the meantime, so you don't even know if this even is an issue. Waste, waste, waste.
Deferring non-critical bugs to the backlog is a good way to create this huge steaming pile of work that, when being realistic, you will never end up doing. New work tends to always be more important and jumping the line, because of deadlines and promises. During backlog sessions, these open bugs are looked at time and time again, and dragged around while they probably will never be fixed. A big waste.
I can't talk for others, but having a huge steaming pile of open bug reports is a good way to smash motivation as well. For me, it always takes a chunk of mental space, even when I decide to ignore it.
When bugs are considered an acceptable thing, it can become normal to introduce bugs with new features. Developers can become senseless to bugs.
When having known bugs, and you introduce code that has to deal with the buggy part, it is commonplace to create workarounds or temporary fixes. This is bloat and debt that often is ignored once a bug finally gets resolved. It makes me cringe.
Forcing to work on bugs first shortens the feedback loop on issues with new features. When bugs emerge on new features easily, it means improvements are to be made in the process itself. Why do bugs slip in? You want to look at code reviews, testing and specifications to reduce the chance of introducing new bugs. Being bug-free is an award on its own, and it can help to grow it as a culture.
Having a bug-free backlog makes you more predictable and gives you more freedom to change focus of work. There is less risk of running into deadlocks, and there is no need for allocated bug-squashing time.
I hope this article inspires both developers and Product Owners to give Zero Bug Policy a shot, as I've outlined the benefits. I think it is all about being realistic and draw a clear line where effort goes, and won't go.
At my current employment we are aiming for the Zero Bug Backlog, we are gradually moving towards it and will give it a try to keep it at 0. It has been a stretch to clean everything up, but it felt very similar to when I first adapted Inbox Zero (which meant cleaning up over 1000 emails).