According to Ward Cunningham, technical debt arises as a consequence of carelessness in code which leads to faster, but imperfect solutions. These development shortcuts are often taken for time or budget reasons. Meticulously prepared, faultless code is difficult and requires a lot of time to produce. Under some circumstances, developers, therefore, opt for messy code to save time and effort. But these savings come with debt.
For Cunningham, this economic aspect of programming is rather normal. If technical debt is not settled with refactoring and the code is not regularly optimized, development can become bogged down or halted due to metaphorical interest.
Marin Fowler, author of Refactoring: Improving the Design of Existing Code, fleshed out Cunningham’s metaphor and subdivided code debt into four types – visualized in the technical debt quadrant:
| Reckless debt | Prudent debt |
Deliberate debt | - Time/budget constraints
- Neglected refactoring
| - Prioritization of quick software delivery and a commitment to refactoring
|
Accidental debt | - Lack of qualifications
- Insufficient documentation
- Overengineering
- Anti-patterns
- Code erosion
| - Constant refactoring resolves programming errors and deficiencies accrued over time and helps to learn from mistakes
|