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.
One thought on “What Technical Debt is and isn’t”
Good post George. I noticed you explicitly call out that Technical debt is not similar to credit card debt, which reminds me of a post we have on our website. https://threenine.co.uk/what-is-technical-debt/ , in which we made a claim.
I just wanted to draw attention, that although you may have intentionally argue the point that Technical Debt should not be compared to credit card debt, you unintentionally seemed to strengthen the case that is actually is and in the process, more or less agreed with us.
The reasoning is as follows, Technical debt, is ultimately about taken intentional short cuts during implementation in order to deliver quicker, accepting that there will at some point in the future some effort required to fix these issues. Thus accepting that bugs, misimplementations, integration issues etc may arise later, but there is a stronger business need to deliver something “good enough” in the short term.
In this case, the business accepts the risk and the potential increase in costs later down the road, but they feel they can manage it.
Which is entirely similar to making a purchase on your credit, you can get the instant gratification but delay the payments to the future, by accepting potential increase in costs later. The debt may initially seem manageable at the time and controllable.
However, things never always go to plan and in the interim you may need to make a number of additional purchases, or in the case of the business some additional short cuts to achieve other goals.
These debts may accrue over time, and you may get to the point, where you only able to pay the minimum balance, i.e. small updates to functionality, but you can never complete the full implementation.
As you pointed out, at some point the business my choose to defer payment of the debt, by re-developing the application, just as you can either by transfering the the debt to a Credit Card provider or by some other lower interest form of loan. But the point is, even in the new application, you may still need address exactly the same scenarios or in effect just take on other forms of technical debt.