Average maintenance/development cost ratio is less than one
Part of the (incorrect) folklore of software engineering is that more money is spent on maintaining an application than was spent on the original development.
Bossavit’s The Leprechauns of Software Engineering does an excellent job of showing that the probably source of this folklore did not base their analysis on any cost data (I’m not going to add to an already unwarranted number of citations by listing the source).
I have some data, actually two data sets, each measuring a different part of the problem, i.e., 1) system lifetime and 2) maintenance/development costs. Both sets of measurements apply to IBM mainframe software, so a degree of relatedness can be claimed.
Analyzing this data suggests that the average maintenance/development cost ratio, for a IBM applications, is around 0.81 (code+data). The data also provides a possible explanation for the existing folklore in terms of survivorship bias, i.e., most applications do not survive very long (and have a maintenance/development cost ratio much less than one), while a few survive a long time (and have a maintenance/development cost ratio much greater than one).
At any moment around 79% of applications currently being maintained will have a maintenance/development cost ratio greater than one, 68% a ratio greater than two and 51% a ratio greater than five.
Another possible cause of incorrect analysis is the fact we are dealing with ratios; the harmonic mean has to be used, not the arithmetic mean.
Existing industry practice of not investing in creating maintainable software probably has a better cost/benefit than the alternative because most software is not maintained for very long.
Provocative article. Interesting idea.
Possible alternative interpretations:
* Maintenance costs in the surveyed projects had been reduced by using good design.
* Programs that were canceled could not survive due to poor design. Software has to be sufficiently maintainable to be continuously maintained and stay competitive.
* Re-implementing a program should count as maintenance of the original version.
* IBM makes more money by re-inventing the wheel than by maintaining it; they have a negative incentive to maintain.
* Maintenance costs are seen as bad; thus true maintenance costs are hidden as “customer support”, developers working “off the clock”, etc.
* When maintenance becomes too expensive, customers are forced to abandon maintenance and accept the increased cost of using buggy software.
@D Herring
Where is evidence for any claim that the ratio is greater than 1?
My experience is that companies are willing to throw a lot of money at expensive to maintain systems, so I don’t expect badly designed systems to be cancelled sooner rather than later.
Don’t forget that this analysis does not include systems that are cancelled before they are ever shipped. A common occurrence that reduces the ratio.
I think the weakness in the analysis is the assumption of fixed maintenance per year. It is easy to envisage maintenance costs decreasing over time, but I have no data on how it might, or might not, decrease over time.
There is also the issue of investing in getting systems to ship in the first place, with any subsequent reduction in maintenance being a side-effect.
There are many successful software products where the maintenance is clearly greater than 1, even when accounting for new feature development. Adobe Acrobat, Photoshop, Oracle, Matlab, MS Windows, and MS Office are just a few well known examples. How many times have vendors been accused of selling a new version of the same old product, with only minor improvements?
Roughly fifteen years ago, I heard an interesting talk by an exec from a large “shrink-wrap” software company. It included a financial breakdown of their operating costs. I forget his specific numbers, but they were approximately 10% management, 20% sales, 50% customer service, 15% maintenance, 5% R&D. He was proud of what a high R&D percentage they had — well above industry standard for a company of their size.
I’ve talked to many others since then, and these numbers hold for a wide range of successful software companies selling shrink-wrap products. They all spend significantly more money on customer-driven bug fixing than on new development. Support contracts are bought for customer service and bug fixing.
You are probably right that most software never reaches this point. There is numerous examples where “worse is better”. My point is just that this needs to be taken with a grain of salt. It is not a hard and fast rule, and there are definite exceptions in industry.
Maybe more software would prosper if developers provided better maintenance and support. Maybe most software is inherently a niche product that does not justify the added costs. Maybe most requirements are so poorly thought out that most projects are doomed regardless of how they are implemented.
Both Corel WordPerfect and Netscape Navigator died when maintenance became unbearable and the attempted re-write failed. There are many other such examples.
Below a certain complexity, it is almost always easier to do a clean re-write than to use fancy design patterns. Above a certain complexity, such re-writes are almost always a waste. Isn’t a re-write an extreme form of maintenance?
I wouldn’t be surprised if small software projects with few users are dominated by development costs and large projects with many users are dominated by maintenance costs. Development is something of a fixed cost to achieve a level of functionality. Maintenance scales with users (usage variations increase code coverage), deployed platforms (OS, hardware, and other variations), and other such factors.