I do not know why “technical debt” is such a common phrase in the developers world? Or why “code rot” is so rarely used as they are both essentially the same thing.
Actually I do know why.
- “Debt” implies that at some point in the future time and resources will be made available to address the short cuts, the rushed code, the fixes to the fixes
- “Rot” implies that what has been created is rotten, dead and worthless.
But how often is time, money and resources allocated to pay back the “debt”? Can you go to a client and say, “Yes its working well enough today but we can make it better” Or how do you demonstrate the return on investment to a client?
Maybe by having an explicit understanding how the rot develops can slow its progress. How about these 3 sources of debt/rot?
- Deliberate debt. Limits on time and money necessitate the need for a quick delivery.
- Accidental debt. Where decisions made early on in a project might not be the best solution as the project evolves and requirements change. Additional new functionality will become difficult and slow to implement. Incremental refactoring might not be the solution and a more rigorous approach to refactoring is needed
- Unnecessary complexity through lots of incremental changes, often exacerbated when multiple individuals or teams work on discrete aspects of the code with out fully understanding of original code or design decisions
I’ve spoken to friends who work in other industries about this and I feel that coding in its many forms suffers from lack of scheduled/planned maintenance. Which is fine until 6/12/18 months down the line something stops working.