Technical Debt is a powerful metaphor: it describes code-quality shortcomings in financial terms; until the debt is paid off we pay interest, meaning that it takes longer to implement new features. It’s a useful metaphor, but has limits. A few weeks ago I was annoyed when a whole room of Agile consultants took seriously the idea of “borrowing on code-quality” to get a start-up off the ground, and then repaying the debt later (presumably by hiring consultants). All my experience tells me that this is a disastrous strategy. Such debt becomes incredibly expensive to pay off – expensive in real cash.

Ward Cunningham coined the Technical Debt metaphor. He describes (on video) producing code without a complete understanding of the problem, as accumulating technical debt. By writing the code early we increase our understanding of the system: as long as the debt is repaid, this is prudent borrowing. It’s quite like a business borrowing to invest in capital equipment and using the increase in revenue to pay off the debt.

Metaphors are natural and useful thinking-tools. A good metaphor, though, can be dangerously seductive. We can be tempted to use it beyond its applicability. A metaphorical vehicle cannot fully describe its topic: they need to differ for it to be a metaphor rather than a description.

Recently Brian Marick suggested that metaphorical reasoning could be improved by listing ways in which the metaphor differs from its topic. Financial debt is easily quantifiable; technical debt is not. Borrowing on code quality to get your product out quickly is more like begging favours from the Mafia than taking out a business loan. The repayment terms are unknown, except that they will be entangling, larger, and more horrific than you can imagine.