The term technical debt, seems to cover all manner of sins these days. It is sometimes used, in my opinion, incorrectly as a motivation to adopt new technologies or features. It is also often used to describe any kind of technical quality issue with a product.
Ward Cunningham the original author of the term indicates that the debt term is about being able to make a gain, in terms of earlier delivery time. Rush the software out to delivery, accepting that the software design and implementation is below expectations. Then quickly refactor the software with gained experience to pay back the debt. Interestingly, he notes that quality of the code must be good, in order to make refactoring manageable.
I recently read an article where technical debt was characterized as being deliberate or inadvertent. This made me reflect on what we mean by technical debt, and how does it fit with QA (quality assurance). The difference being that technical debt can be a good thing, it helps you deliver a product earlier at a cost of correcting the debt in the future. An issue with QA, for example poor code or poor design, has no gain what so ever, it provides only a constraint on future development.
I would define technical debt as having three characteristics:
- There is a decision to accept the debt, debt doesn’t just appear.
- There is a clear value gain from the debt, for example in terms of delivery time.
- There is a specific intention to pay the debt back in the short-term
The decision to accept debt means that we know there is an expectation of how we should be delivering something, but we intentionally choose a sub-optimal implementation in order to gain a specific value, often quicker delivery. If it is a technical debt, we are aware that it exists and we have an intention to fix it, in the short-term. That suggests that we have a plan for managing the debt, for example, probably tasks or stories in your backlog.
Technical debt differs from QA issues. If the product is suffering from quality issues, such as poor code, no designs or weak architecture, this is not technical debt in my view. This is just poor quality, there is no gain to delivery time, there is no trade-off. While technical debt is controlled, QA is perhaps more inadvertent and indicates that action is require in the QA processes to ensure better quality. This is not the case with technical debt. The decision to take on technical debt is made knowingly, and is not a QA issue unless it doesn’t get fixed as promised.
It is also worth remembering that quality and debt are outcomes. What is really interesting is the causes of poor quality or rising technical debt. In the case of technical debt, we might find that a continuous pressure on delivery causes growth of technical debt. There is no time for the development team to pay back the debt, so the debt grows exponentially. If the debt is left too long it will eventually come to a point where it is no longer debt but a constraint, it will be simply too expensive to fix and the best that can be done is damage limitation.
With regards to quality issues these are identified and resolved by employing good QA practices, for example, tests, mentoring or reviews. Quality issues appear unexpectedly when the QA practices are not sufficient to identify quality issues early in the development process, for example, badly written code or poor design. Unlike technical debt there is no value gain, in fact, the delivery of the product would probably be faster if the quality had been maintained in the first place. However, just like technical debt, if these issues are not addressed in the short-term, they will come to a point where it is just too expensive to fix, and this will place a constraint on the product. I think the important take-away here is that technical debt is intentional and is a good thing if used wisely. So long as you look after your debt and pay it back in a timely fashion, the trade-off for a quicker delivery time can be very advantageous. However, quality issues are never a good thing, these only lead to problems with the product and give no value gain. These should be minimized by continually improving QA processes and fixing the issues at the earliest opportunity.
Architecturality 