In my previous posts we looked at symptoms of bad code and reasons we write bad code. And bad code leads to technical debt. Ward Cunningham introduced the Technical Debt metaphor by stating:
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt.”
Ward Cunningham, 1992
In other words
- Neglecting the design is like borrowing money and taking out a loan
- On going development slows down because of the neglected design and the complexities it has introduced. The slow down is like paying interest on the loan
- Every minute spent on not-quite-right code counts as interest on that debt
- Refactoring reduces the complexity and eventually speeds up development. It’s like paying off the principal debt
Jim Highsmith1 defines technical debt in terms of Cost of Change. The difference between our optimal cost of change curve and our actual cost of change curve is our technical debt. Notice how technical debt increases overtime and that directly impacts our ability to respond to our customer’s requirements. Soon the product becomes unmaintainable.
In my next post, I’ll discuss how not all debt is bad and the difference between good debt and bad debt.
1 – http://jimhighsmith.com/the-financial-implications-of-technical-debt/
