Technical debt

Original author: Martin Fowler
  • Transfer
Software systems tend to accumulate garbage  - internal flaws that make it difficult to further modify and expand the system compared to ideal code. Technical debt is a metaphor invented by Ward Cunningham. She explains how to perceive this garbage, by analogy with a financial loan. Additional efforts required to add new features are interest on the loan.

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

What attracts me the most in the debt metaphor is a clear understanding of the costs of servicing or eliminating it. I can spend five days cleaning the modular structure, removing garbage, metaphorically paying the “lender”. If I do this for this function, I will lose out because I will spend nine days instead of six. But if there are two more such functions, then it’s more profitable to remove the garbage.

With this formulation, the task becomes purely mathematical. Any manager with an electronic tablet will solve it. Unfortunately, we cannot measure performance , so no costs are objectively measurable. We can roughly estimate how long it takes to develop the function, how long it will take to work after removing the garbage - andassume 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. In 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 with the removal of garbage, future changes become cheaper. The big advantage of incremental improvement is that we naturally spend more time removing trash in frequently changing areas. These are precisely the areas of the code base that are most in need of garbage disposal.

Comparison of interest payments with the payment of principal debt helps to determine what kind of garbage to deal with. If I have some particularly terrible area of ​​the code base, then the problem disappears if it turns out that it is not profitable to delete garbage. Interest is paid only when you have to work with this part of the software (the metaphor is a bit lame in this place because you always have to pay on a bank loan). Thus, nightmarish but stable areas of code can be left alone.

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

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

The danger here is that often this analysis is erroneous. Trash very quickly begins to harm, slowing down the introduction of new features. As a result, developers exceed credit limits and release the product later than if they would immediately spend time providing higher quality. Here, the metaphor often misleads people, because the dynamics of technical debt do not actually correspond to the dynamics of financial loans. Assuming debt to speed up the release of the product only works if you stay below the design payoff line in the hypothesis of architecture sustainability , and developers cross it after a few weeks, not months.

Debates are regularly held on whether various types of garbage should be considered debt. It seems to me that it is useful to take into account whether a duty is taken consciously and reasonably - or recklessly. So a square of technical debt appeared .

Further reading

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

There is a video recording where Ward Cunningham discusses his metaphor.

Dave Nicolette expands Ward's view of technical debt by providing a fine example of what I call reasonable intentional debt .

Several readers have suggested other valid metaphors. David Panarity called low-quality development a programming shortage . Apparently, he began to use the term several years ago when it was consistent with government policy; I guess now it’s relevant again.

Scott Wood suggested treating “ technical inflation as soil loss when the current level of technology so far exceeds your product level that it gradually falls out of the environment. Programs lag behind in versions of the language to such an extent that the code is no longer compatible with the main compilers. "

Steve McConnell highlighted several good points in the metaphor. In particular, as a reduction in unintentional debt leaves more room to intentionally accept debt when it is helpful. I also like his formulation of minimum payments (which are too high to fix problems in embedded systems, but not on sites).

Aaron Erickson talked about financing Enron .

Henrik Kniberg claimsthat the old technical debt is causing the biggest problem, and that it’s wise to establish a high-quality debt ceiling to make it easier to manage.

Eric Dietrich discusses human loss due to technical debt : team battles, skill degradation, and burnout.


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

Also popular now: