When we look at technical debt, we see a metaphor that checks all three boxes: it has a number of useful points of correspondence; the points of difference don’t overwhelm the core idea; it is familiar. Furthermore, it brings with it a useful working vocabulary. For example, consider what the following debt-related words suggest to you in a software context: repayment, consolidation, creditworthiness, write-off, borrowing.
Although we know that by definition no metaphor is perfect, there are two common ways in which the metaphor is misapplied: assuming technical debt is necessarily something bad; equating technical debt with a financial debt value. The emphasis of the former is misaligned and the latter is a category error.
If we are relying on the common experience of our audience, financial debt is almost always thought of as a burden. If we take that together with the common experience of code quality and nudge it with leading descriptions such as “quick and dirty,” it is easy to see how in everyday use technical debt has become synonymous with poor code and poor practice. We are, however, drawing too heavily on the wrong connotation.
Rather than reckless debt, such as from gambling, we should be thinking more along the lines of prudent debt, such as a mortgage. A mortgage should be offered based on our credit history and our ability to pay and, in return, we are able to buy a house that might otherwise have been beyond our reach.
Source: On Exactitude in Technical Debt, Kevlin Henney, https://www.oreilly.com/radar/on-exactitude-in-technical-debt/