What do you do when you find a bug? Tackle it now or lock it away. Does it matter? Many will argue the benefits of choosing the right time to fix it, but does it really add up? Could delay be a little too convenient?
In most cases we:
- Discover it – either ourselves or it’s reported by a user, either way we need to check it’s real
- Log it
- Assess whether it should get fixed and prioritise
- Stick it in some kind of backlog
- Create a test and fix based on information in backlog
Why? The bug might not be worth fixing or fixing might not add as much value as another story in the backlog and so it should be prioritised. This leads to a number of possible outcomes all with different costs:
- Bug will never be fixed and is deleted – Just the cost of logging and assessment, well until somebody finds it again and the whole process starts again with an annoying feeling of de-ja-vu
- Bug should not be fixed but will stay logged – As above but when it’s found again it should be quicker to dismiss – you now have to maintain lists of old bugs, accumulation of technical debt
- Bug will be fixed but not right now – Cost of logging assessment and backlog management, and inconvenience caused to the customer until it’s fixed, accumulation of technical debt
- Bug will be fixed immediately – cost of logging, assessment and of interruption to existing backlog work
An alternative is
- Discover it
- Create a test and Fix
Why? Ok, so perhaps it might not need to be fixed but we can eliminate all the logging and assessment and rediscovery above by just fixing it. Whats more since the bug will usually be recreated as part of the discovery step the developer can quickly create a test and fix while it’s fresh in everyones mind. Fixing immediately reinforces a stop-the-line mindset allowing us to learn from the immediate feedback before we potentially do more damage. In a solid code-base where bugs are rare and can be easily fixed, I’m dubious there is ever a good reason to delay the fix. If bugs take a considerable time to fix you need to take a look at the way you are coding.
What do you think?
Diary of a ScrumMaster 
Don’t step over the poo.. clear it up
😀
“In a solid code-base where bugs are rare and can be easily fixed, I’m dubious there is ever a good reason to delay the fix. If bugs take a considerable time to fix you need to take a look at the way you are coding.”
Whoa, there’s a nice sweeping statement to end on…
Aren’t you assuming a closed environment where the code is the *only thing* whereas in reality code depends on the external environment, and the external environment changes.
When the external environment, browsers, OSs, interweb tubes etc., change they can break things, if you have no record (or one that’s buried in tests and source repositories) how are others in the org e.g. support staff going to know about the issue etc.
Yes there’s a case for logging, fixing and testing certain types of bugs immediately, but there’s also a case for deferring other more difficult / less important issues if there are other priorities.
Also if you don’t track how do you know what are the common problem areas, which types of problems occur most often.
Even simple clear code can have complex interactions when combined with other simple clear code, some bugs are just hard to crack.
Thanks for the comment Andy. Yes point taken, bugs that involve externalities particularly where you don’t have the source code can be a nightmare, if it can’t be fixed in a couple of hours I would consider logging. IME experience bugs that take this long are very rare, I appreciate I’m lucky.
I don’t really buy databases of bugs being a useful tool for improvement, but thats just my experience. IME the cost is much greater than the benefit.
Nice article, Tom.
“The bug might not be worth fixing or fixing might not add as much value as another story in the backlog and so it should be prioritised.”
How do you think something should *ideally* be given a priority? Is it the internal project owner? In my experience, the client or third-party isn’t able to rationlise this so everything becomes a priority.
Yes, I think its very hard to compare the value of fixing a bug against the value of adding a feature. It’s to easy to ignore the cost of living with bugs particularly if we are naturally optimistic. If it had to be done then project/product owner seems a good candidate however they are unlikely to consider the ongoing cost of the technical debt. Much simpler just to fix it!
Tom, thanks for writing this up. The point that I was attempting to make last week was that I believe there is actually an implicit decision being made in between steps 1 and 2 in your list above – perhaps in fact, step 3 should be duplicated and one of its entries swap with step 2 and another be inserted between steps 4 and 5.
The process that you’ve outlined above doesn’t feel as though it has enough inquiry in it – I’d like to see more assumptions (which means being able to state them upfront) being tested before the bug is just fixed. Having said that, I’ll accept that there are always bugs that should just be fixed straight away – those that are causing your software not to functional at all and those that mean some text needs to be aligned for example.
Dan