Technical debt is a metaphor, coined by programmer Ward Cunningham, for the future cost you take on when you choose a quick or easy solution now instead of a better one that would take longer.
Like financial debt, it lets you move faster in the short term, and you pay interest later. That interest shows up as extra time to add features, more bugs, harder debugging, and slower onboarding for anyone new to the code. If you never pay down the principal (by refactoring, rewriting, or cleaning up), the interest compounds until even small changes become slow and risky.
Common sources
- Shortcuts taken to hit a deadline, such as hardcoded values, copy-pasted code, or skipped tests
- Outdated dependencies, frameworks, or server software left unpatched
- Missing or stale documentation
- Design decisions that made sense at the time but no longer fit how the system is used
- Code that grew organically with no overall structure
Deliberate vs. accidental
Debt can be a conscious trade-off (“ship now, clean up next month”), which is often reasonable if you actually follow through. It can also be accidental, arising from inexperience or from requirements that changed after the code was written. Both kinds are real, but the deliberate kind is easier to manage because you know it exists.
Managing it
You don’t need to eliminate all of it. The practical approach is to keep track of known debt, fix the parts that slow you down most often, and clean up as you touch code rather than waiting for a big rewrite. Debt in code you rarely change costs little, while debt in the code you modify every week is expensive.
The term is also used more loosely now for similar costs outside of code, such as “design debt,” “documentation debt,” or “infrastructure debt.”
