Concept dictionary
Technical Debt
Expedient software design or construction choices that increase later change cost.
- Review state
- Reviewed in POC
- Freshness
- Current
- Version
- 1
Also called
- Technical Debt
- Tech Debt
Remember it this wayMove sooner now; pay more to change it later.
In plain language
Technical debt appears when a software approach helps a team move sooner but leaves the code or architecture harder or more expensive to change later. The original choice may be rational. The debt is the extra future work created by the technical context that choice leaves behind.
Why it matters
Unmanaged technical debt raises development and sustainment costs and can narrow the team's options. Making it visible lets the team decide which debt is useful, which debt is becoming risky, and when repayment is cheaper than building another layer on top of it.
Example
To meet a release date, a team copies the same validation rule into four services instead of creating one maintained component. The release ships sooner, but the next rule change must be found, updated, and tested in four places.
Common misconception
Technical debt is not every bug, old component, or imperfect design. It describes a technical approach whose short-term benefit creates a context in which later work costs more. Some debt can support exploration when it is visible and managed.
Related terms
Sources
- Software Engineering Institute, “Managing Technical Debt in Complex Software Systems”defines technical debt as a short-term expedient design or construction approach that makes the same work cost more later, and notes that managed debt can support design exploration.
Learn more
- [CMU SEI technical-debt overview](https://www.sei.cmu.edu/library/managing-technical-debt-in-complex-software-systems/).
- Compare with [[debt|Debt]] for the RS family boundary and [[rework-loop|Rework Loop]] for one possible operational consequence.