Technical debt is an obligation that an organization incurs when it chooses a design or construction approach which is expedient, but increases complexity and is more costly in the long term. That is, some aspects of quality are deferred for the sake of faster delivery.
The metaphor of technical debt is compared to monetary debt. If it is not repaid, it accumulates ‘interest’, making it harder to implement changes later on. Another way to view it is that when technical debt is not addressed it results in increased software rot in the case of software.
The term originated in software development, but may be applied to other fields. This entry describes the term as applied to software.
Technical debt includes, for example, postponement of:
- Refactoring code to reflect improved understanding of the software design and architecture
- Refactoring code that is confusing and difficult to modify
- Writing automated tests
- Fixing bugs
When technical debt accumulates there are various harmful effects to the business, such as:
- It becomes increasingly difficult to implement new functionality
- Stakeholders are upset when new features take longer and longer to deliver
- Developer morale decreases
- Delivery timelines become less predictable
Note that technical debt is not inherently good or bad. It depends on how it is used, what the tradeoffs are, and what the intent is. The following five-minute video with Ward Cunningham who originated the term is clarifying.
Background of the Term
The metaphor was described by Ward Cunningham in the article The WyCash Portfolio Management System
Further Learning
Technical Debt – ProductPlan – blog post
Technical debt – Wikipedia – wiki post
