Monday, December 8, 2008

The business value of fixing defects

Less defects is always a good thing. Right? Not so fast. Fixing a defect has both benefits (more obvious) and costs (often easy to ignore). In this posting, I'll concentrate on some of the costs and why they can sometimes outweigh the benefits. This analysis is performed from the perspective that everything we do in a software project has to come in line with adding value to our stakeholders.
First, let's discuss the opportunity costs. Allocating resources to fixing a defect takes away from doing other things - such as fixing more important defects or implementing new features. The way to prevent misallocation of precious resources in an agile setting is to treat defects as any other quantity of work - create stories for them and, based on a prioritization exercise that takes into account feature stories, work them into the backlog. In a non agile setting, misallocation of resources due to high opportunity cost is trickier. Since prioritization is usually fractured between requirements and defects, defects usually get prioritized among themselves and get fixed within the allotted time. This usually leads to inefficiencies - since very seldomly the predetermined time for 'fixing bugs' is just right. Many times, teams will over fix some parts of the code and under fix others. There is also a temporal horizon bug fixing problem (I'll deal with that more in depth in a separate entry) - in brief, more recently discovered bugs tend to be fresher in people's minds, and thus, receive more attenting than older bugs.
Second, fixing bugs is risky. Touching a piece of code runs the risk of introducing more bugs, in other words, doing more harm than good. This risk should be managed by the project manager just as she would manage any other project risks. This is particularly heinous since time and attention for retesting are often in short supply.
To conclude, I'm not advocating against fixing defects. The point I'm making is that fixing defects should be treated as any other quantity of resource consuming endeavor, and as such, it should be balanced against other resource demands from the perspective of getting the most bang for the buck for the project stakeholders.

No comments: