Let’s Replace the Term “Technical Debt”

If you work in software for any length of time, you’ll eventually hear of the term technical debt. It refers to something that isn’t that well designed and will be a costly maintenance headache in the future. It’s supposed to conjure scary images of short-term technical shortcuts causing future pain.

While well-intentioned, I think the term is useless. Let’s first examine why, and then consider an alternative.

“Technical Debt” just isn’t scary

The word “debt” has never taken first place in any scary word competition. I’m not holding out hope for a Hollywood production of Nightmare on Elm Street: Freddy Sells Predatory HELOCs.

Most people who own a home have a mortgage, and businesses already take loans from banks. While too much debt can of course be crushing, it is used in too many non-scary situations to also be a boogeyman concept.

It’s Not Effective

“Technical Debt” is too abstract to convey business risk. Debt can be paid off, and in a way that is manageable. Imagine meeting with your CEO or board and explaining that the latest product release has created technical debt. If you’re lucky you’ll just get an eye roll, or perhaps an “And…?” question as a response.

Nobody in the business world knows what to tell technical leaders to do with technical debt, because it is something only technical leaders really understand. Bringing it to the business table can be seen as an unwelcome annoyance.

It’s Not Quantifiable

There’s a big difference between:

• having a debt of $1 vs. a debt of $100 million
• having a debt due next week vs. due in 10 years
• having a debt with no interest vs. a loan with enormous interest
• being indebted to a close family member vs. to murderous gangsters

But if all I tell you is “I have debt”, then you have no way of knowing how bleak my future really is.

Similarly, I’ve heard the term “technical debt” used about a mediocre 50-line function as well as about a misguided choice of technology stack used in a vast multi-team project. Issues with the former were solved in a 15-minute refactoring session, but the massive problems caused by the latter were never solved. Yet the same “technical debt” term was used to describe both of these completely different situations.

It has become a truly useless term.

The Replacement Term Is: Two Terms

What we need instead is something that:

• Suggests urgency and business risk
• Prompts actionable decisions
• Is somewhat quantifiable

One term probably cannot satisfy all of those requirements. Instead, using two terms which identify opposite ends of a spectrum holds more promise.

And that’s why I propose we throw “technical debt” away, and use technical liability and technical asset instead.

Technical Liabilities and Assets

“Technical debt” does not naturally cause a discussion of consequences or resolution plans, but framing things as technical liabilities can do that. It more effectively evokes images of impending risk for people in non-technical roles.

If you tell your CEO or product managers that you’ve got a “technical liability” on your hands, they will be more likely to sit up and pay attention more than if they had just heard about technical debt. “Technical liability” does a far better job conveying urgency and risk.

Conversely, by only having the term “technical debt” in our conversations, we have fewer ways to celebrate the wonderful work done by engineers to create elegant, maintainable software. By adding technical asset to our regular vocabulary, we bring more opportunities to do exactly that.

Qualifiers can be used on the liability/asset scale to make the term quantifiable. For example:

“The simplicity of this interface makes it a significant technical asset, but the underlying protocol handshake is so murky that it is a major technical liability…”

I’ve already eliminated “technical debt” from my day-to-day conversations, and I now use technical liability and technical asset instead. I hope you will consider doing the same.