Why Bug Fixing Can Be Hazardous To Your Project
Submitted by Dave Churchville on Tue, 2006-06-06 13:33.
Stop fixing that bug right now! You could be putting your project at risk without even knowing it.
When I first started developing software over 15 years ago, I thought that bugs were evil, and should never appear in any software. It was a matter of personal honor, integrity, and pride to eliminate any bugs.
Only one problem with that approach. There is an opportunity cost to every bug you fix. And there is a risk factor as well.
Once upon a time when I fixed a small cosmetic problem with a data input screen, all seemed well, I could check it off my list, and make sure there were no bugs associated with my name.
That fix made it into production, and it wasn't long before customers discovered that they couldn't save any data when a certain field had a certain value.
Guess who introduced that problem while fixing a minor cosmetic issue?
This problem wasn't dicovered in testing because it only occured with the right combination of fields selected. But it still broke the software.
To make things worse, no one actually told me to fix that bug, I just assumed that I should, because it was there.
Years later, when I became a development manager, I had a different mindset. I still didn't want to see bugs in a shipping product, but once the product went out, I carefully evaluated any bug reports from the field.
I treated every bug like an enhancement request - something to be evaluated for it's value, impact and risk.
A bug fix has value when it addresses an issue that is causing a non-trivial problem for a customer. It has impact when it a large number of customers share that problem, or when one of your major customers is complaining. The risk factor, then, is how likely you are to inadvertently introduce more problems by fixing the bug.
Now, we always strive to create clean, efficient, well-tested code, but some areas are scarier than others. If a fix to a carefully tuned algorithm, or a complex AJAX presentation can't be exhaustively tested, it represents an unknown risk factor.
Can you live with the bug that you've got now, or are you willing to live with the possibility of a more significant one being introduced?
So you can finish fixing that bug you're working on, but do it with your eyes wide open. Know your risks, your value proposition, and the kind of impact you're expecting.
Blind bug-fixing is like polishing an explosive device. It will look really shiny until it blows up in your face.
How do you prioritize your bug fixes?