Technical debt is a human-made conceptual metaphor in software engineering that frames accumulated code quality degradation as a financial debt instrument. The metaphor maps development shortcuts — writing quick solutions instead of well-architected ones — to borrowed capital that accrues interest in the form of increased future development cost, reduced adaptability, and higher defect rates. It persists through developer awareness, documentation of known shortcuts, prioritization frameworks that weigh refactoring against feature work, and the recurring tension between delivery speed and code quality. The construct is not literal debt: no creditor exists, no principal is owed, and the interest rates are estimated, not contractual. Its power lies in making abstract quality trade-offs legible to both engineers and non-technical stakeholders. [formal: technical debt | substrate: mind | horizon: hours | explicit: no | epoch: 0.95]
Accepted ontology entry
technical-debt
Technical debt is a human-made conceptual metaphor in software engineering that frames accumulated code quality degradation as a financial debt instrument. The metaphor maps development shortcuts — writing quick solutions instead of well-a…
Definition
Why it is in scope
A human-made conceptual metaphor: the practice of treating accumulated code quality degradation as a form of debt that accrues interest in the form of increased development cost and reduced adaptability. Built to persist through project documentation, team communication, and architectural decision records.
Names and aliases
- technical-debten · CANONICAL
Relations from this entry
- cmrcn3xe200bk13vzrvoavi4uINSTANCE_OF →
Technical-debt is a specific kind of debt: the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. The specific→general relation: technical-debt IS a particular domain of debt (engineering/software).
Relations to this entry
- cms9k3mvj01ci7skqjfrbmy7g← SERVES
code-review is maintained for the sake of managing technical debt: its designed purpose is to catch defects, poor designs, and architectural drift before they enter the codebase, preventing them from accumulating as debt.
- cmrwxi74g01ogsoac4imftqrf← SERVES
refactoring is maintained for the sake of managing technical debt: its designed purpose is to improve internal code structure without changing external behavior, directly reducing accumulated debt.
Record identity
- Created
- Jul 31, 2026, 4:49 PM UTC
- Content hash
- 3e1eacf65efb5657bd47d009025d826047e5a3c711d192291b4051b3bc5641f7