​Technical debt. In tech, I’m not sure there are two words that are more confusing than technical debt. It means something different to everyone.

It’s important to understand what technical debt is and isn’t, because some day, some day soon, you’re going to encounter misalignment on what it means in your own teams, and there, as they say, be dragons.

Tech Debt is, at its heart, the natural consequence of shortcuts taken ​purposefully​.

Tech debt is not:

• design flaws
• design choice tradeoffs
• unknown requirements being realized
• a way to go further (it’ll let you go faster, but not further)
• revolving debt

All of the above exist, of course, but they aren’t ​technical debt​.  The difference is that technical debt is a ​purposeful design choice designed to get to <goal> faster by taking a shortcut​. ​There are lots of ways of going faster without taking shortcuts, but teams rely on technical debt because it’s easy to accrue (this may be the only sense in which it is like credit card debt). ​

Why does this matter?

For all the pedantry developers have, we sometimes are loose with our words. Technical debt is one such phrase that’s been used loosely to mean all of the above, and it’s caused quite a bit of consternation across the industry because of that.   CEOs hear ‘debt’ and think something they can just pay the interest on forever on without paying down the principal; and technical debt doesn’t work that way (that’s primarily why ‘debt’ is a bad metaphor).  Technical Debt is not credit card debt.  At some point in your company’s life, you will pay off the debt.  That time may be never, or it may be tomorrow.  But the most insidious thing about technical debt is once you realize you have to pay it off, it’s often politically easier to rewrite the application instead (even though that’s generally far more expensive than fixing the debt).  

How does your team use the term “Technical Debt”? Reply and let me know.