Technical Debt
Technical Debt
A metaphor coined by Ward Cunningham to describe the characteristic of software systems that unless proactive efforts are made to keep the software well-architected and easy to understand, the ability to make meaningful progress with new features will degrade over the life of the system.
Understanding Technical Debt
(McConnell, 2008) categorises technical debt in two classes, with a further expansion of the second:
| Class | Kind of debt | Comment |
|---|---|---|
| 0 | Non Debt | Feature backlog, deferred features, cut features, and so on. Not all incomplete work is debt. These aren’t debt, because they don’t require interest payments. |
| I | Unintentional Debt | Debt incurred unintentionally due to low quality work |
| II | Intentional Debt | Debt incurred intentionally |
| II.A | Short-Term Debt | Short-term debt, usually incurred reactively, for tactical reasons |
| II.A.1 | Focused Short-Term Debt | Individually identifiable shortcuts (like a car loan) |
| II.A.2 | Unfocused Short-Term Debt | Numerous tiny shortcuts (like credit card debt) |
| II.B | Long-Term Debt | Long-term debt, usually incurred proactively, for strategic reasons |
Type I technical debt has no upside, and if discovered in significant amounts remedial action should be taken immediately to improve skills and practices.
All the variants of Type II Technical Debt may have upsides, but awareness and conscious decision-making is critical - for that reason type II.A.2 is dangerous because of the ease with which it happens and the compounding of negative consequences.
Reasons for taking on technical debt
Like financial debt, there can be good reasons for a company to consciously decide to take on technical debt - it is a decision to prioritise short term benefit over the longer term.
Typical reasons might be:
- time to market (do this to get the release out on time, fix it after)
- preserving startup capital
- delaying development expense - if a system is going to be retired, all its technical debt is retired with it!
Tracking and communicating technical debt
Again good examples in (McConnell, 2008) such as maintaining a "debt list" in the defect tracking system or as work items in the product backlog.
Communicating technical debt to non-technical colleagues can be done by presenting tradeoffs in financial terms - e.g. comparing both short-term and lifetime costs of different options.