Technical debt comes at us in many different places. Alves et al. have covered this in their paper “Towards an Ontology of Technical Debt.” In this post, I want to explain what defect debt is, where it originates from, how to solve it, and also why it should be solved.
What Is Defect Debt?
Again, let’s look at how Alves et al. define defect debt:
Software projects may have known and unknown defects in the source code. Defect debt consists of known defects, usually identified by testing activities or by the user and reported on bug track systems, that the CCB agrees should be fixed, but due to completing priorities, and limited resources have to be deferred to a later time. Decisions made by the CCB to defer addressing defects can accumulate a significant amount of technical debt for a product making it harder to fix them later.
Side note: CCB is an acronym for (Software) Change Control Board. Basically, it’s the person or group of persons responsible for deciding which changes will be made to a piece of software.
The last sentence in that quote is the important one. Not fixing known defects is a form of taking on technical debt. What is that?
Not fixing the defect could allow faster delivery of other features. So, like other categories of technical debt, there is an advantage to taking on defect debt. But there is also a cost. For example, not fixing the defect could mean teams must handle support requests about the known defect.
Causes Of Defect Debt
In the technical debt quadrant, there is a distinction between known and unknown technical debt. However, the authors of the papers mentioned above speak only of known defects in the case of defect debt.
I don’t see how defect debt could be unknown, because it’s about defects that were reported but where the decision makers chose not to fix them.
You may think that unknown defect debt is about unknown defects in the code. But in that case, there is no deliberate decision to take a short cut, so it can’t be considered technical debt.
So defect debt is caused by postponing the fixing of reported bugs. That in itself is not such a big problem. Teams must weigh the benefits and the costs. Sometimes, there are workarounds for users, or maybe only a small set of users is affected. But creating too large a backlog of unfixed defects will cause frustration among users and developers.
Solving Defect Debt
In my experience, most organizations try to take on a good balance between implementing new features and fixing known defects. So I don’t regard defect debt as a big problem. All organizations have some amount of defect debt, but it is usually tracked well and repaid as soon as possible.
Solving defect debt starts by assessing which bugs must be fixed first and then ensuring there is time for a decent fix.
Some organizations have a strict policy of fixing any incoming bug as soon as possible. This is of course a great way to keep defect debt extremely low. But it is usually acceptable to postpone some bugfixes. For each defect, decision makers will have to consider what the priority is for fixing it, and whether or not a workaround is good enough for stakeholders.
The Business Case For Reducing Defect Debt
The reason to keep your defect debt under control comes down to the satisfaction of your customers, end users and developers.
End users and customers can become frustrated with software that is riddled with bugs. More so if they start feeling that the software provider isn’t putting effort in fixing the bugs. If a better and more stable product exists, they may consider moving to that option. This will affect your income and profits.
Even worse, you may get a reputation for delivering faulty software. Once you do start fixing the bugs and reduce your defect debt, you may never recover from the damage to your reputation.
Apart from customers, it’s also worth keeping defect debt low because it may frustrate developers when they aren’t allowed to fix bugs they know are there. Developers want to be proud of the product they’re building. If they’re unhappy with the state of the product, it may be a reason to start looking for a job at an organization that takes software quality seriously.