Elizabeth Hendrickson recently discussed the wasted hours she spent in bug triage meetings. In her blog testobsessed.com she addressed the problem that some organizations spend so much time and money on testing without really leveraging the information testing reveals.
As she explains in her article, there is a common and mistaken notion in the software engineering community that bugs are inevitable, and that not all of them can be fixed which is why "it makes sense to make a fix/defer decision on bugs based on some notion of ROI".
She has been employed in two companies where this line of thinking has turned out to be deathtrap. The companies have not been killed by the bugs directly. But, as Hendrickson explains, the bugs became a "pervasive infection" that slowed down productivity and paralysed the testers and engineers. In detail,
it was the hidden costs that drained us of life: hours lost arguing about bugs in bug triage meetings; hours lost stumbling over the same known issues again and again; hours lost fighting with a fragile and error-prone code base to make even small changes; hours lost cataloging and categorizing the backlog. It was demoralizing and immensely expensive.
Hendrickson draws a couple of conclusions from her experiences.
Cancel all the bug triage meetings; spend the time instead preventing and fixing defects. Test early and often to find the bugs earlier. Fix bugs as soon as they’re identified; attend to your broken windows early.
Readers of the blog have commented on this article. For example, Jim Gay adds:
I’ve seen bugs that indicated that the business process was wrong. For example an analyst tells you it should do X so you code X and then the users ask why it isn’t doing Y. Either a bug in the code or a bug in the process means something should be fixed.
Gabe Newcomb does not agree to all statements of Hendrickson:
This implies that all bugs are worth fixing — and that the effort to fix them is more important than any new functionality. That doesn’t match my experiences. The process of bug triage (as I am used to it) answers important questions such as when (and whether) to fix an issue, and where it fits in relation to other work. How would you propose answering these questions?
Steve Fenton is a developer who believes that all bugs should be fixed because:
The time it takes to fix a bug is nearly always less than the time it takes to allow it to endlessly loop around. As well as the customer impact, an old bug is discussed in meetings, is accidentally raised again and again by testers and then closed as a duplicate again and again by developers. The longer it hangs around, the more chance there is for it to cost more than it would have cost to fix it straight away.
