Time has a significant impact on projects. You need to get to market. You need to respond to change quickly, but also remain responsive over time, which makes it critical to build maintainable systems. Add to that competition and the technology landscape, plus the cost of delay, and the cost of change can become quite high.
According to Cutter Consortium Senior Consultant John Heintz, the increasing cost of change leads to a slowing down of customer responsiveness.:
“One of the primary reasons that we slow down is because it gets harder and harder to change things. If the cost of change in our systems goes up, then at some point we become less responsive, and we slow down.”
This is where technical debt comes in. Heintz define technical debt as two things:
- Technical debt is an indication of the total remediation cost. You don’t want to remediate all the way down to zero but to a responsibly low level, and then stay at that responsible level — not to trend up. So it is an effort cost to fix measurable problems in the code base.
- Technical debt is an indication of future risks of failure. It can give you a hint at how risky projects are to your future cost of change or reliability in production.
When customer responsiveness has started to fall off precipitously, according to Heintz, there are only three strategies you can apply:
- Do nothing, and likely everything will continue to get worse. Your customer responsiveness will continue to go down.
- Replace the system in a big rewrite. This is, of course, a high-cost and high-risk endeavor.
- Invest in incrementally refactoring and cleaning up the system, paying down that technical debt.
None of these strategies is easy, and all have consequences. But, says Heintz, “Once you have gotten to a significantly high cost of change and low customer responsiveness they are the only options left.”
Get Additional Insight into Technical Debt
Cutter Research: Cutter clients can read John Heintz’ Cutter Business Technology Journal article, Using Technical Debt to Make Good Decisions, in which he presents short case studies of organizations that chose one of the 3 strategies described to improve customer responsiveness: Story 1: The Online Broker That Refactored; Story 2: The Online Retailer That Rebuilt; Story 3: The Tool Vendor That Increased Technical Debt.
Enterprise architects and IT executives recognize the problem of technical debt, but what do they do without the resources and funding to deal with it? States Mohan Babu K in Why Do Organizations Take on Technical Debt?, they need tools and techniques to communicate the problem to their stakeholders and engage with them.
Cutter Consortium Consulting and Training: In a Technical Debt Assessment and Valuation, Cutter Consortium’s Senior Consultants examine the quality of the software under examination through technical and business lenses.