Over 90% of the cost of software development is software maintenance (cite). This alarming trend was predicted as early as 1972. McKinsey suggests that CIOs should spend no more than 40-60% on maintenance. Gartner’s IT Spending and Demand Survey (2002) reports that CIOs are spending 80% of their budgets on maintenance (p12 of presentation). Agile development can help reverse this trend.
The Cost Trends of Software Maintenance
Jacoozi published an analysis of the impact of continuous refactoring on software maintenance costs. Continuous refactoring is an element of agile software development, where the developers continuously make minor improvements to the architecture and design as they maintain the code.
Thanks to Levent Gurses for providing this modified version of the chart from his article, Continuous Refactoring and ROI. In his article, he discusses both recurring “big bang” refactoring (the pink curve) and continuous refactoring (the green curve).
What Levent’s chart shows with the black line is that the cost of maintenance grows at a significant rate over time when you don’t refactor the code.
We can re-use the diagram from our earlier analysis of agile development and ROI, and overlay this cost structure. The green curve represents sales volume, contrasted with the shaded curve representing development costs.
In the product lifecycle diagram above, there is an initial “hump” of development cost. Note that when you are using incremental development, the hump extends past the end of the development stage of the product life cycle.
The largest part of the shaded area represents the ongoing costs – 90% of which are maintenance costs. Note – we are assuming that companies use a rational investment strategy – they continue to maintain the software until the costs equal or exceed the revenue. The investment should stop when the opportunity cost of continued investment exceeds the benefits of continued investment.
Broken Windows
Continuous refactoring is making small investments in improving the code over time. The absence of those investments allows the code to grow more expensive to maintain over time. Gartner estimated that 50% of the cost of ongoing maintenance labor is spent trying to understand the existing code base. This is very inefficient.
In The Tipping Point, Malcolm Gladwell described this phenomenon by analogy to the broken windows in East New York City. This is just one gripping example from his book of the same title.
As the code gets more convoluted over time, these two factors serve to increase costs dramatically – the increased difficulty of doing the job, combined with increased apathy about doing it right. Costs would go up simply because the code gets larger (as the software is expected to do more and more). These factors accelerate the rate at which the phenomenon occurs – consistent with Levent’s faster than linear cost growth function.
Fixing The Windows
When faced with the challenge of reducing the ongoing maintenance costs, you have a few choices:
- Eliminate Ongoing Maintenance and Development. This was the Autodesk strategy (fire the engineers, milk the product for revenue). It worked great for a very short time. Profit growth was tremendous. This of course accelerated the decline in sales, eliminating revenue (and therefore profit).
- Reduce Spending On Maintenance and Development. Simply reducing the budget has all of the negative impact of cutting the budget, but with fewer gains. A reduced budget (with no other changes) increases the frustration both of unstatisfied customers and of overwhelmed developers. This is a bad idea.
- Refactor The Code To Improve Efficiency. You can make ongoing maintenance more efficient by making the code easier to understand and modify. This generates cost savings – the “big money” in ROI calculations.
Improving efficiency reduces the costs of ongoing development, as the following diagram shows:
Other Benefits
By reducing the cost of ongoing maintenance, you can improve the profitability of the product. You also free up resources for investment in new product development. This helps move your organization to McKinsey’s recommended 40% to 60% maintenance budget.
You will also get intangible benefits and improved efficiency by reducing the number of broken windows in the product’s code base. This results in increased motivation of the team members and greater job satisfaction. The increase in motivation will decrease the cost of development of other functionality.
You may also extend the useful life of the product – by extending the amount of time when ongoing maintenance is still profitable. This additional development work could result in increased sales – extending the product life cycle.