Glossary · Engineering Leadership
What is technical debt?
Short answer
Technical debt is the future cost of shortcuts and outdated decisions in software: code, architecture or infrastructure that works today but makes every later change slower, riskier or more expensive. Like financial debt, some is a reasonable trade for speed; left unmanaged, the “interest” of slower delivery and more incidents keeps growing.
Common forms
- Outdated languages, frameworks or dependencies, such as an unsupported PHP version.
- Missing tests, so every change needs slow manual checking.
- Tangled code where one change breaks unrelated features.
- Manual deployments and undocumented infrastructure.
How to make it visible
Debt is hard to prioritise until it is expressed in business terms: lead time for changes, incident counts, time spent on rework, security exposure from unpatched dependencies, and cost of running old infrastructure. Track a few of these over time.
Paying it down
- Reserve a steady share of each iteration (often 15–25%) for improvement work, rather than waiting for a rewrite.
- Fix debt where you are already working, the “boy scout rule”.
- For large legacy systems, replace them gradually with the strangler fig pattern.
- Watch new debt from AI-generated code: it arrives faster, so reviews, tests and static analysis matter more, not less.
