In my previous posts, we looked at symptoms of bad code and reasons we write bad code. 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.”
Or, as Cunningham puts it even more simply –
“Neglecting the design is like borrowing money. Refactoring, it’s like paying off the principal debt.”
“Developing slower because of this debt is like paying interest on the loan. Every minute spent on not-quite-right-code counts as interest on that debt.”
With technical debt, we can choose to continue paying the interest by moving slower and slower, or we can pay down the principal by refactoring the quick and dirty design into the better design which will lead us to higher productivity. So although it costs to pay down the principal, we gain by reduced interest payments in the future.
Jim Highsmith 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 over time 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, as well as the difference between good debt and bad debt.
What is Technical Debt is the third in a seven-part series on Technical Debt from Excella Software Development Lead Fadi Stephan.
Part 1: Top 4 Symptoms of Bad Code
Part 2: Top 5 Reasons Writing Bad Code Happens
Part 3: What is Technical Debt?
Part 4: Good Technical Debt vs. Bad Technical Debt
Part 5: The Vicious Cycle of Technical Debt