Loading content
Technical debt describes deferred or suboptimal technical decisions that speed short-term delivery but degrade long-term maintainability and development velocity. The concept covers code, architecture, and process debt as well as strategic risks. It provides a decision framework to assess, prioritize, and gradually repay these liabilities.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What you need to understand to reason about a domain.
Technical debt is the future cost created by fast or incomplete technical decisions.
Ward Cunningham introduced the metaphor in 1992 to explain the short-term benefit of pragmatic software decisions and their later interest costs. Martin Fowler expanded it into a model of deliberate or inadvertent deferral.
A shortcut saves time today but later creates friction in change, operation, or understanding. Interest keeps accruing; repayment means targeted improvement.
Principal is the original technical shortcut taken on.
Interest is the recurring extra cost of development and operation.
Repayment reduces the cause through refactoring or migration.
The debt model makes maintenance and cleanup plannable. Teams can prioritize risk and connect quality investment with product work.
Where this building block is located in the topic model.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.