Software systems are prone to the build up of cruft – deficiencies in internal quality that make it harder than it would ideally be to modify and extend the system further. Technical Debt is a metaphor, coined by Ward Cunningham, that frames how to think about dealing with this cruft, thinking of it like a financial debt. The extra effort that it takes to add new features is the interest paid on the debt.
The metaphor of debt is sometimes used to justify neglecting internal quality. The argument is that it takes time and effort to stop cruft from building up. If there new features that are needed urgently, then perhaps it’s best to take on the debt, accepting that this debt will have to be managed in the future.
The danger here is that most of the time this analysis isn’t done well. Cruft has a quick impact, slowing down the very new features that are needed quickly. Teams who do this end up maxing out all their credit cards, but still delivering later than they would have done had they put the effort into higher internal quality. Here the metaphor often leads people astray, as the dynamics don’t really match those for financial loans. Taking on debt to speed delivery only works if you stay below the design payoff line of the Design Stamina Hypothesis, and teams hit that line in weeks rather than months.
There are regular debates whether different kinds of cruft should be considered as debt or not. I found it useful to think about whether the debt is acquired deliberately and whether it is prudent or reckless – leading me to the Technical Debt Quadrant.
See also The Human Cost of Technical Debt – the human side of the problem. And, make no mistake — in business, all human problems are also business problems,viewed with a wide enough lens. Unhappy humans are unhappy workers, and unhappy workers are less productive. Yet, this angle of technical debt is seldom discussed, in my experience.
- Unpleasant Work
- Team Infighting
- Atrophied Skills
- The Hidden Business Cost: Turnover and Attrition