Technical debt: when metaphors go wrong
I'd like to find an alternative to the term "technical debt", but I doubt I could convince people to adopt it. Technical debt is so ingrained in the programmer's consciousness that we seem to confuse metaphors with synonyms. Metaphors are to synonyms as transvestites are to my wife (and that's an analogy I'm sure she's going to bring up over the dinner table).
Technical debt bears a resemblance to actual debt, but it's not the same thing. Like actual debt, it's accrued in the same currency (skilled labor over time) that must be used to pay it off. Like actual debt, it's often desirable if you need something now and can't wait for it.
We were discussing in email at work when Abigail put the nail in the coffin of the "technical debt is actual debt" debate. Specifically:
- Sometimes it's OK to default on technical debt (code rewrite, proof of concept, business requirements change, and so on)
- Monetary debt has a schedule on which you must pay it. Technical debt does not.
Got that? When you encounter technical debt in your code, you can decide to repay it or not. Try telling that to your bank. Or if it's in an old, stable part of your code which rarely needs updating or changing, is spending money refactoring that code more valuable than adding a new feature which might earn money?
When you see "technical debt", ask yourself, "do I need to repay this now?" If your answer to that is always "yes", you're a zealot and I'd rather not be programming with you in a professional environment even if I welcome your work in an open source environment. Technical debt is not debt, but we've heard it called "debt" for so long that we act as if it really is debt (I'm guilty of this too). Don't make that mistake.