Technical debt is a metaphor introduced by Ward Cunningham to explain the cost of shipping code that is not quite right. He first set it out in an experience report for OOPSLA 1992 about the WyCash portfolio management system, where he wrote that shipping first-time code is like going into debt: a little debt speeds development as long as it is paid back promptly with a rewrite.
In Cunningham’s original framing, the danger comes from leaving the debt unpaid. Every minute spent on code that is not quite right counts as interest on that debt, and entire engineering organizations can be brought to a standstill under the debt load of an implementation that is never consolidated or refactored. Object-oriented design, he argued, makes it more practical to keep paying the debt down.
Martin Fowler, who has popularized and refined the metaphor, explains that the debt framing helps teams decide when to clean up code. Code that is changed often demands what he calls a zero-tolerance attitude to cruft, because the interest payments there are cripplingly high, while code that is rarely touched can be left messier without much cost.
Fowler also warns that the metaphor is often abused. Teams sometimes invoke technical debt to excuse low quality, but neglecting code quality usually makes delivery slower, not faster. Repaying the debt means refactoring: improving the internal structure of the code so future work becomes cheaper again.