Technical debt is the implied cost of future work created by choosing a faster or easier solution now instead of a better approach that would take longer. It’s a metaphor borrowed from finance: like financial debt, technical debt accrues “interest” — the longer it sits, the more it costs to fix, and the more it slows down future development.
The term was coined by Ward Cunningham in 1992.
You’ll hear this when…
“We’re carrying a lot of tech debt” means the codebase has accumulated shortcuts, outdated patterns, or unmaintained code that makes new work harder and riskier. “We need to pay down tech debt” means the team wants to allocate time to refactoring and cleanup.
Tech debt comes up in roadmap discussions, sprint planning, and engineering leadership conversations. It’s a constant negotiation between shipping features (which often creates debt) and maintaining code quality (which pays it down).
Intentional vs. accidental
Some tech debt is deliberate — the team knowingly takes a shortcut to meet a deadline, planning to fix it later. Some is accidental — the team didn’t know a better approach existed, or requirements changed and the old approach no longer fits. Some is environmental — libraries fall out of date, APIs get deprecated, and standards evolve.
The danger isn’t having tech debt — every codebase has some. The danger is not tracking it, not planning for it, and letting it compound until the codebase becomes too expensive to maintain.
Source: Ward Cunningham’s original debt metaphor (1992)