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…
- …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.
- …it is cheap, because financial debt has been cheap in recent decades. Yet developers know that “technical debt” is often very expensive.
- …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.
- …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.
- …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.
- …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
- Stop trying to fix technical debt
"...we should start describing the actual issues the code faces, and what they mean for the business and for the users. Which happens to be precisely what leadership wants to talk about." — Ricardo Lopes - Stop saying “technical debt”
Chelsea Troy shares how this phrase gets in the way of clear communication - Anything But Tech Debt
Emily Nakashima highlights the value of using more specific language to describe your "tech debt" - Tech debt traps to avoid
Pat Kua highlights some of the traps that you can fall into when using the term "Tech debt" - Technical debt: Can investing in it unlock 2x team impact?
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
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. - We sound like idiots when we talk about technical debt
Kam Lasater lays out the pitfalls of talking about technical debt and how we can do better - Take control of your code quality
My talk on how to take control of your code quality - How To Explain Technical Debt To Executives. Hint: It’s Not Technical.
Sam McAfee encourages us to focus on the organisational side of "technical debt" - Is high quality software worth the cost?
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
The origins of the "technical debt" metaphor - Technical debt is an overused and lazy metaphor
Ben Morris on some of the issues with "technical debt" and communication - Technical Debt – Bad metaphor or worst metaphor?
Ron Jeffries muses on the value of technical debt as a metaphor - Principles behind the Agile Manifesto
These 12 principles form the basis of the Agile Manifesto and I regularly refer back to these when making decisions