/\/\   ___   ___ ___  ___  ___
 /    \ / _ \ / __/ _ \/ __|/ _ \
/ /\/\ \ (_) | (_| (_) \__ \ (_) |
\/    \/\___/ \___\___/|___/\___/

A collection of Joel Chippindale's infrequent reckons

Technical debt is a terrible metaphor

A good metaphor helps us communicate our ideas by providing an easier way to approach them. A bad metaphor gets in the way of clear communication.

“Technical debt” is a metaphor that is often used in software development as part of trying to explain some of the trade-offs we make when designing software, and the costs that we incur because of the lack of quality in our software.

However, the metaphor “technical debt” often hides a whole host of misunderstandings.

Here are some of the many ways that this metaphor confuses communication.

When people hear the “technical debt” metaphor, it suggests to them that…

  1. …the cost will be predictable, like a financial loan’s interest payments. Yet developers know that the cost of “technical debt” is unpredictable. It is hard to assess up front and is likely to vary as the context that they are working in changes.
  2. …it is cheap, because financial debt has been cheap in recent decades. Yet developers know that “technical debt” is often very expensive.
  3. …we are making explicit choices about when to accumulate it, like choosing to take out a loan. Yet developers know that “technical debt” is often accumulated without discussion or explicit decision making.
  4. …it is quantifiable and constant, like financial debt. Yet developers know that it is not quantifiable in any meaningful way and it can be radically changed by shifts in external context.
  5. …each bit of “technical debt” is interchangeable, like money. Yet developers know that some bits of “technical debt” are much more costly than others and it matters which bits you choose to pay off.
  6. …there can be code with zero “technical debt”. Yet developers know that all code is a liability and all valuable code has “technical debt”. This sets unrealistic expectations for developers and stakeholders.

The biggest problem in communication is the illusion that it has taken place. With so many misunderstandings built into the metaphor of “technical debt”, is it any wonder that conversations about prioritising work on “technical debt” are frustrating?

If you are finding your own conversations about “technical debt” frustrating then take some time to reflect on whether any of these misunderstandings might be occurring. If they are, then it is probably worth explicitly talking about them.

An alternative is not to use a metaphor at all. Talk in concrete terms. Talk about the specific work that you recommend to and/or are carrying out to improve code quality and the positive impact that this will have on developer productivity.

Further reading and watching