8 Questions to Ask before Fixing a Defect

Defect fixes can be costly and risky—sometimes moreso than the defects themselves. With a little insight, you can determine whether a defect should be fixed or left on the ash heap of history.

Every fixed defect is a link in the chain of quality. Numerous unfixed minor defects and cosmetic issues lead to doubt about the accuracy of the application’s more complex functionality, blemishing the entire product and possibly the company’s reputation.

There are some good reasons to fix a defect. Any defect in calculations, lost revenue, security, loss of life or injury, or a noticeable decrease in performance usually leave little doubt about their need for correction.

However, every code fix is a potential risk, increasing the possibility of generating new defects. This is especially true when fixing backlogged defects. These stale defects become more risky to fix because of the need to refamiliarize yourself with previously written code from people who may no longer be there. Additionally, the resources spent fixing backlog defects are in direct conflict with future development.

Not all defects are created equal, so careful thought should be applied before a defect is fixed. The goal isn’t to fix every reported defect; it’s to return value to the customer and profit to the company.

The “defect parallax effect” is where an issue appears to vary when viewed from different perspectives. Determining if a defect is worthy of fixing requires analysis from all possible usage scenarios, stakeholder positions, and consequences.

These questions can help in the decision-making process.

1. Severity: What are the consequences when this issue arises?
2. Probability: What is the likelihood that the problem will surface?
3. Incidences: How many times has this issue been reported?
4. Time: How long has the problem been in existence?
5. Cost: What is the price for this fix? It’s the time needed to fix, deploy, and test, including updates to automation scripts and documentation.
6. Risk: Is the fix risky enough to introduce new defects? Not only should the code complexity be taken into account, but also the competency of people doing the fixing, deploying, and testing.
7. Delay: What potential work are you sacrificing in order to fix this problem?
8. Reporter: Who found the defect? If it was your bosses’ boss or a high-profile customer, it may warrant a fix no matter your responses to the previous questions.

Most companies want their customers to be delighted all the time, but that’s unreasonable. Fixing every reported issue is irrational, so sometimes acceptance of software’s imperfections is a more reliable route to moving the product forward.

Your defect database is a report card on your software development process. Taking a more long-term approach to software quality is advisable. It’s better to spend the time fixing the root causes of the reported defects and obtaining qualified resources than fixing defects.

Break the mindset of “We never have enough time to do it right, but always enough time to do it over.”