Technical Debt
Technical debt is the future cost a software team takes on when it chooses a quicker or simpler solution today instead of a better one that would take longer. Like financial debt, it can be useful when taken deliberately, but it charges interest: every later change to the affected code takes more time and carries more risk until the debt is repaid.
How Technical Debt Works
Ward Cunningham introduced the metaphor in a 1992 experience report on the WyCash portfolio management system. His point was that shipping first-time code is like borrowing: a little debt speeds development as long as it is paid back promptly, and the danger comes when it is not.
The metaphor has three parts:
- Principal: the work needed to fix the shortcut, such as restructuring a module, replacing a hard-coded value or adding missing tests.
- Interest: the extra effort every future change costs while the shortcut remains. If a feature takes six days instead of four because the code is tangled, the two extra days are interest.
- Repayment: refactoring or redesigning the code so the interest stops.
Martin Fowler adds a useful distinction between deliberate debt, a conscious trade-off made to hit a date, and inadvertent debt, which builds up through carelessness or because the team only later learns what a better design would have been. Debt also matters more where code changes often. A stable module nobody touches can carry shortcuts cheaply; a module edited every sprint cannot.
Why Technical Debt Matters
Technical debt turns engineering shortcuts into a product decision. It slows delivery of the roadmap, raises the chance of defects and makes estimates less reliable, often without anyone outside engineering seeing why. When product managers understand it, they can decide openly when taking on debt is worth it, for example to test a minimum viable product with real users, and when to reserve capacity to pay it down.
It has become more pressing with AI-generated code. Coding agents produce working code quickly, but they can also repeat a flawed pattern across many files before anyone reviews the architecture, so the principal grows faster than it used to. The technical debt blueprint for solo builders shows how to catch these architecture flaws at the requirements stage, before code is written.
Technical Debt Example
A two-person startup hard-codes a single currency to launch its billing page in one week. That is deliberate debt, and it is reasonable while every customer pays in dollars. Six months later the team signs its first European customer. Adding euros now means touching invoices, reports and the database schema, and the work takes three weeks instead of the few days it would have taken with a currency field from the start. The team logs the fix as a backlog item, repays the principal, and future currencies become a configuration change.
Technical Debt vs. Bugs
A bug is behavior that is wrong: the software does not do what it should. Technical debt is usually invisible to users. The software works, but it is harder and slower to change than it should be. Unpaid debt often produces bugs over time, which is why the two get confused, but they are diagnosed and prioritized differently.