Technical debt is a metaphor for the extra work you take on later when you choose an expedient implementation now. Like financial debt, it lets you ship sooner but charges interest: every future change in that area is slower and riskier.
Why it matters
Some debt is a reasonable trade, for example launching an MVP before a deadline. Unmanaged debt, however, makes features take longer, causes more bugs and frustrates developers. Teams that track it can decide deliberately when to repay it, usually through refactoring.
Example
A team hard-codes shipping rules in five places to meet a launch date. Months later a new carrier is added, and a developer must find and edit all five, missing one and causing wrong prices. Repaying the debt means moving the rules to one module, which takes a few days once but saves effort on every later change.
Common mistakes
- Treating all messy code as debt; code that is ugly but never changes costs little.
- Never scheduling repayment, so the interest compounds until work grinds to a halt.
- Taking on debt without recording it, so nobody remembers why a shortcut exists.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.