Software systems tend to accumulate debris - internal flaws that make it difficult to further change and expand the system compared to the ideal code. Technical debt is a metaphor invented by Ward Cunningham. She explains how to take this garbage, by analogy with a financial loan. The extra effort required to add new features is interest on the loan.



Imagine that in my codebase there is a module of confused structure. Need to add a new feature. If the structure was clear, then the work would take four days, but with this garbage it takes six days. The difference of two days is the interest on the debt.

What attracts me most in the metaphor of debt is a clear understanding of the cost of servicing or eliminating it. I can spend five days cleaning the modular structure, eliminating garbage, and having metaphorically paid the “lender”. If I do this for this function, I will lose, because I will spend nine days instead of six. But if there are two more such functions, then it is more profitable to remove the garbage.
')
With this formulation, the problem becomes purely mathematical. It will be decided by any manager with an electronic sign. Unfortunately, we cannot measure productivity , therefore no costs are objectively measurable. We can roughly estimate how long it takes to develop a function, how much work it takes after garbage is removed - and assume the cost of removing it. But the accuracy of such estimates is rather low.

Therefore, usually the best option is to do what we usually do with financial debts: gradually pay the principal amount. On the first function, I will spend an extra couple of days to remove some of the garbage. This may be enough to reduce interest on the debt, so that in the future it can be repaid in one day. This is still extra time, but after removing garbage, future changes are cheaper. The great advantage of a gradual improvement is that naturally we spend more time on garbage removal in frequently changing areas. These are the areas of the code base that most need to remove garbage.

Comparing interest payments with principal payments helps determine which garbage to deal with. If I have some particularly awful area of ​​the code base, then the problem disappears if it turns out that it is not profitable to remove garbage. Interest is paid only when you have to work with this piece of software (in this place the metaphor is a little lame, because you always have to pay a bank loan). Thus, nightmarish but stable areas of the code can be left alone.

Unlike stable parts of the code, areas of high activity require zero tolerance for garbage because interest payments are extremely high there. This is especially important since garbage accumulates where developers make changes, regardless of quality: the more changes, the greater the risk of garbage.

The debt metaphor is sometimes used to justify poor code quality. The argument is that quality code takes more time and effort. If you urgently need new features, it is better to take on the debt and deal with it later

The danger here is that this analysis is often wrong. Garbage very quickly begins to harm, slowing the introduction of new functions. As a result, developers exceed credit limits and produce a product later than if they immediately spent time on providing higher quality. Here, the metaphor often misleads people, because the dynamics of technical debt do not really correspond to the dynamics of financial loans. Taking on debt to speed up product launches only works if you stay below the design payoff line in the architecture sustainability hypothesis , and the developers cross it in a few weeks, not months.



There is a regular debate about whether various types of garbage should be considered debt. It seems to me that it is useful to take into account whether debt is taken consciously and rationally - or recklessly. So there was a square of technical debt .

Further reading

As far as I can tell, Ward first introduced this concept in a report for OOPSLA 1992 . She was also discussed on the wiki .

There is a video where Ward Cunningham discusses the metaphor he had invented.

Dave Nicolette extends Ward's view of technical debt, giving an excellent example of what I call intelligent deliberate duty .

Several readers suggested other suitable metaphors. David Panariti called substandard development a programming deficit . Apparently, he began using this term several years ago when he was in line with government policies; I guess this is now again relevant.

Scott Wood proposed to consider “ technical inflation as a loss of soil when the current level of technology is so much higher than the level of your product that it gradually falls out of the environment. Programs lag behind in language versions to such an extent that the code is no longer compatible with the main compilers. ”

Steve McConnell highlighted some good points in the metaphor. In particular, reducing inadvertent debt leaves more room for intentionally accepting debt when it is useful. I also like his wording of minimum payments (which are too high to fix problems in embedded systems, but not on websites).

Aaron Erickson talked about financing Enron .

Henrik Knberg argues that the old technical debt is the biggest problem, and that it is reasonable to establish a high-quality debt ceiling to make it easier to manage.

Eric Dietrich discusses human losses due to technical duty : battles in teams, degradation of skills and burnout.

Edits

This post was originally published on October 1, 2003. I completely rewrote it in April 2019.