Ovid suggests that technical debt is a misleading metaphor. He's right in that, like any metaphor, the surface comparisons are more similar than the deep correspondences. Yet it's a useful metaphor even at the surface level.
(I haven't asked Ward Cunningham about this directly, but I've heard secondhand that he originally spoke of technical debt as the compromises of the business requirements of software. In other words, every time you guess as to what the software should do instead of verifying what it should do, you take on technical debt. It's not about quality in this model, it's about correctness.)
The idea of debt and technical shortcuts is useful if you consider that debts in the real world often have interest payments and can reduce your cashflow and at some point require your creditors to come calling around to liquidate your assets. It's useful in an advanced way when you successfully leverage short term debt for long term gains. It's not useful when you consider that managing debt in a real and successful business (or even on your own) benefits from an understanding of leverage, inflation, repayment schedules and amortization, taxation strategies, goodwill, depreciation, and securitization.
(Then again, software people are bad about metaphors. Electronic readers aren't books and don't require you to flip pages. Also the construction industry works nothing like most programmers and project managers seem to think. Construction is more like software than software is like idealized construction.)
I tend to think of this thing-previously-known-as-technical-debt as friction. The weight bench in the closet to the right of my desk in my office may have a lot of friction, but it rarely matters because I haven't moved it in three years and I'm not likely to move it any time soon. (If I do move it, my weekend is ruined already, so I don't care if it glides across the floor like some sort of elegant ice dancer.)
I do care if something gets jammed in the casters of my chair, because I move around every couple of minutes and only notice when I can't move.
The more difficult it is to make a necessary change to a piece of code you need to change—the more difficult it is to continue to make changes—the more technical friction you have. If you don't need to make changes, or if you need to make one quick, small change and that's it, a lot of friction doesn't matter too much. If you're constantly making changes, a little bit of friction matters a lot.
I do still like the metaphor of debt for two reasons. It suggests that technical practices, even in moderation, can pay down the debt of a piece of code. That's good. That gives people hope. It also uses the language of finance and money to express the value of a piece of code. (Code is a means to an end. Remember that.) The notion of rubbing butter on a stubborn API (or pouring extra virgin olive oil on an API by removing deprecated parts of it) fails to inspire me in the same way.
I use the language of technical debt, knowing that the metaphor is incomplete and flawed, but I think about identifying and removing friction—not just to start moving but to continue moving.
