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 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.
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.