Hardly any metaphor is more important for software development than “technical debt”. But unfortunately, it has some weaknesses. Above all, teams usually do not consciously decide to go into debt.
Users or project managers cannot really see how good the quality of the code of an application is. After all, only developers know whether the code is easy to modify or not. Unfortunately, compromising quality is dangerous. In extreme cases, poor quality can bring a project to a complete standstill. As a metaphor, technical debt should make the problem of quality easier to convey. This helps users or project managers to better understand why not every feature should be implemented “quick and dirty”.
Wikipedia
Wikipedia describes technical debts as follows: If a team immediately puts code into production without any consideration of quality, it will deliver faster at first. But the team is building up technical debt. Just as with monetary debt, interest must be paid: Productivity is reduced because poor code quality is holding up the team. This description fits well with the metaphor: Whoever takes out a loan builds up debt in order to do an investment faster. But he / she then has to repay the debts later and with interest on top.
Ward Cunningham
Originally, Ward Cunningham introduced the metaphor of technical debt at the 1992 OOPSLA Conference. On YouTube, he explains the term differently: Code always represents the current understanding of the problem solved by the software. When the team learns something new, the code must be consolidated through refactorings. Only then the code optimally represents what they have learned. If the refactorings are omitted, technical debt piles up and the code becomes more difficult to change. Cunningham explicitly excludes that the team might make compromises on quality and therefore clearly contradicts the Wikipedia article. The team does not build up debt, but the debt arises involuntarily.
Martin Fowler
Martin Fowler has a different perspective: either the project team is prudent and makes decisions about quality or it is so reckless that it just ignores quality. Furthermore, the team deliberately compromises quality or technical debt arise inadvertently. He defines four quadrants by prudent/reckless on the one hand and deliberately/inadvertently on the other. The Wikipedia definition is prudent and deliberate: The team knows the quality (prudent) and deliberately makes the decision to compromise on quality. Cunningham’s explanation is prudent because the team knows the quality. However, the technical debt do not arise deliberately, but inadvertently. The team is learning and the code does not yet reflect what has been learned. This cannot be avoided.
I think there is another source of technical debt: technical progress. New architectures and technologies make old approaches obsolete. If the code is not updated appropriately, technical debt arise. This too is inadvertently because it cannot be prevented.
How to deal with technical debt?
However, the most important thing about technical debt is how to deal with it. No system is perfect. This means that teams can always optimize something. However, if the team does not expect an improvement in productivity as a result of an optimization, or if this improvement is lower than the effort to do the optimization, then the optimization should be omitted. Investments can be a good metaphor for this. Quality is not an end in itself, but only a means for improving productivity. If the investment in quality does not pay off with higher productivity it does make any sense to do the investment. Even for this approach, the metaphor of technical debt has an advantage: the compromises concerning quality can be problematic. They are not easy for users or project managers to understand and can lead to the project coming to a standstill. The term “technical debt” expresses exactly this risk.
tl;dr
Technical debt is a metaphor for quality in software projects with some weaknesses and different interpretations. Most important, however, is how teams deal with the technical debt.