Finding a bug in your application actually means you have at least two kinds of problems: symptoms and process issues. To deal with quality in a sustainable way, you have to fix both!
Symptoms
Symptoms are what’s visible to the eye. From a user perspective it’s unexpected or undesirable behavior in the applications that leads to a bad user experience. From an engineering point of view it’s incorrect code or bad design choices.
By fixing the code and the design we get rid of the symptoms.
So let’s do that! Perhaps you recognize the saw-toothed shape of the bug count over time? Many teams regularly do “bug bashes” (and fix only symptoms) when they feel they have reached a too high bug count (also known as the “Oh shit!” level). But if that’s all you do, the bug count will rise again and you have to to another bug bash after some months.
The bug count rises since the number of bugs created is higher than the number of bugs found and fixed during normal development.
Process issues
Clearly, fixing only symptoms is not enough. We have to make sure our mistakes don’t happen again and again, creating an endless stream of new bugs. Finding the answers to these two questions can help with that:
- How did the bug end up in the code?
Nobody intends to create bugs, so somewhere a developer has made a mistake. What can we do to prevent such mistakes from happening in the future? - Why didn’t we find the bug sooner?
The bug slipped all the way through to production and affected the end users. Our safety nets didn’t catch the bug in time. What can we do to catch bugs more effectively and earlier in the implementation process?
Fixing these problems means we have to change the way we work, i.e. improve our processes. Doing so means that we address the source of the bug rate and hopefully reduce it to close to zero in released software. You may still create bugs in development, but they are fewer and only a fraction of them slip through to production affecting end users.
Making this happen isn’t easy. It will not happen in one go as the graph above suggests, it will take several iterations, but it’s doable.
However, don’t cut corners when improving your process. I have seen teams that spend the majority of their development cycle regression testing and fixing bugs in order to stop shipping bugs. Of course you protect the end users from bad user experiences, but at the cost of a very low velocity. This may be a necessary action to take initially, but it’s not a place where you want to be for very long.
The goal is to have high quality and high velocity at the same time and I have seen many teams do that, so it’s not an impossible dream. This is where retrospectives and root cause analysis come in handy.
To get some ideas on what to do, read my follow-up post “Fixing bugs is not a business decision”, coming soon.
Great post! I personally see bugs as opportunities to improve, rather than problems 😉
I would eventually add a third point, which is how can I improve debugging effort in order to fix bug in less time next time (when I cannot ensure that it will not happen again). For instance improving the logged information, etc.
regards,
thomas
Nice post ! I agree with you fully on part of process issues. Many teams do retrospectives and root cause analysis and become aware of the things they must fix in the process to prevent future bugs. This analysis is the easier part. Identifying time and resources to do these process improvements is a different ball game altogether. This is where I think approaches like the improvement kata will help.
Thanks!
I often hear that teams don’t have time to do process improvement, but I tend to disagree.
Scrum teams, for example, own their own time. Every sprint is a fixed time box and it’s the team that decides the scope for the sprint during sprint planning (usually based on the velocity from previous sprints). Deciding the scope is the same as deciding what to do with your time, so to make room for process improvements you can simply pick fewer items into the sprint backlog.
This will temporarily lower your velocity, but if haven’t made room for process improvements earlier you have missed out on increasing your quality and speed for some time. By starting to do continuous improvement you will soon make up for the lost velocity and more.
Can you share a link to the follow up article on how to do this?
You got me! I haven’t written it yet. Will link to it as soon as I do.