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.
The 'Zero Bug Policy' explained
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.
Where are the gains
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.
I like my bugs fresh
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.
Avoid the endless backlog
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.
Raise the quality
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.
Become predictable and flexible
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.
Final notes
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).
Sources:
Top comments (3)
I really like the idea of picking up the bugs when they are still fresh and to pick up the essential ones immediately.
But why not have a list of non-essential bugs just in case, it's a slow Friday afternoon.
I also think that non-essential bugs are nice stories for a new team member to pickup. A good way to get up to speed with the codebase.
And in the end all bugs are essential. How can there be a bug that never needs attention and can be discarded?
I don't agree that all bugs are essential. Fixing bugs requires work - I have a finite amount of work that I can expend on the product that I am building. I can choose between fixing a bug that affects 0.5% of my customers resulting in 20% of them failing to convert that is a 0.025% conversion impact for me. Let's say my average revenue per transaction is $1000 then this bug has a 2.5c per transaction impact.
Alternatively I can use that same time to build some new functionality that that I have tested and looks good for a 50c - $1 positive impact on revenue per transaction.
There is no way I consider that bug "essential" until such time as my next most valuable piece of work is less valuable than 2.5c per transaction.
Yeah, I guess you can keep it out of your backlog itself but keep them on the s ide. So you have some nice-to-have improvements for indeed, those slow friday afternoons or new developers that can get their teeth into the codebase with some issues that are not so daunting.