Engineering glossary
Technical Debt
Technical debt is the future cost, risk, or constraint created when an engineering decision makes later change or operation more difficult than a better-supported alternative would.
In plain language
Technical debt is not automatically poor engineering. A team may deliberately accept a shortcut to learn sooner, provided the consequence is understood. Debt becomes dangerous when it is invisible, compounds through repeated workarounds, or prevents safe change.
Why it matters to a business
- Explains why apparently small changes can become slow or risky
- Helps teams compare remediation with product work using business consequences
- Makes maintenance and architectural constraints discussable rather than mysterious
How it works
- 1A decision saves time or complexity now but creates a future obligation.
- 2The obligation accumulates interest through slower delivery, incidents, fragile tests, or operational work.
- 3Teams identify, describe, and prioritize debt against measurable risk and roadmap needs.
- 4Remediation can be incremental, opportunistic, or a bounded modernization effort.
Common use cases
- Outdated dependencies blocking upgrades
- Duplicated business rules causing inconsistent behavior
- Missing automated tests around critical workflows
- A rushed integration that cannot recover safely
Important implementation decisions
- Business consequence and likelihood
- Cost of remediation versus continued interest
- Whether to contain, replace, document, or accept the constraint
- How to prevent the same debt from recurring
Common mistakes and misconceptions
- Calling every imperfection technical debt
- Assuming all debt must be removed
- Using the term without describing business impact
- Scheduling a broad rewrite instead of bounded remediation
Limitations and trade-offs
Eliminating all debt is neither realistic nor necessarily valuable.
Deferring remediation can be rational when the affected system is stable, low-risk, or near retirement.
Need to apply this concept to a real system?
A focused technical discussion can identify the decisions and constraints that matter before implementation.