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 to help 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” has the potential for many unspoken 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.

.  .  .  .  .  .  .

This is part of a series of articles about Engineering Leadership. I offer coaching and mentoring to engineering leaders if you are interested in further developing your leadership skills.

.  .  .  .  .  .  .

Further reading and watching

• Anything But Tech Debt [article]
  Emily Nakashima highlights the value of using more specific language to describe your "tech debt"
• Tech debt traps to avoid [article]
  Pat Kua highlights some of the traps that you can fall into when using the term "Tech debt"
• Stop saying “technical debt” [article]
  Chelsea Troy echoes the issues with using the term "technical debt" and offers good practical advice for improvement
• Technical debt: Can investing in it unlock 2x team impact? [article]
  Fergus Doyle is very clear, "...when it comes to conversations with exec teams, boards or stakeholders outside of technology, I have never once seen the term technical debt be useful."
• Get specific: on the dangers of making assumptions about technical terms [article]
  Martha Henson on the dangers of making assumptions about technical terms let's be honest, labels like "technical debt" "product manager" or "agile" mean different things to different people in different cases. We need to deal with it by getting specific.
• Take control of your code quality [video]
  My talk on how to take control of your code quality
• How To Explain Technical Debt To Executives. Hint: It’s Not Technical. [article]
  Sam McAfee encourages us to focus on the organisational side of "technical debt"
• Is High Quality Software Worth the Cost? [article]
  Martin Fowler highlights that developers often justify attention to quality by justifying through the need for proper professionalism. But this moralistic argument implies that this quality comes at a cost – dooming their argument.
• Technical Debt: The Man, the Metaphor, the Message [article]
  The origins of the "technical debt" metaphor
• Technical debt is an overused and lazy metaphor [article]
  Ben Morris on some of the issues with "technical debt" and communication
• Technical Debt – Bad metaphor or worst metaphor? [article]
  Ron Jeffries muses on the value of technical debt as a metaphor
• Principles behind the Agile Manifesto [article]
  These 12 principles form the basis of the Agile Manifesto and I regularly refer back to these when making decisions

Questions or feedback

If you have any questions, feedback or advice that you would like to share on this subject then please don't hesitate to contact me at @joel@monkeysthumb.co.uk or joel@monkeysthumb.co.uk.