Jeroen’s weblog

In Jeff Moad’s 1990 Maintaining the Competitive Edge, for which I can’t find an online version unfortunately, he predicted that in 1995, 95 percent of software life-cycle costs would be devoted to maintenance. In 2000 Len Erlikh wrote in Leveraging Legacy System Dollars for E-Business that by then 85 to 90 percent of the IS budget is typically spent on operating and maintaining legacy systems. A good overview of the numbers is maintained by Jussi Koskinen on his page on Software Maintenance Costs. Even though it’s an understudied area, the existing numbers clearly show an upward trend (even though Moad was overestimating it a bit): in the 70s and 80s maintenance was already in the 50-70 percent of total software costs. Starting with the 90s it’s 75 percent and up. In Modernizing Legacy Systems, Seacord et al. refer to this as the legacy crisis.

So does this mean that every hour spent writing new code causes people to spend up to nine hours fixing bugs? Not really. I’ve written about the types of maintenance before and a very important thing to understand is that fixing bugs is rarely the major activity during maintenance. The four types of maintenance can be divided into two groups: corrective and non-corrective. The most influential study in this area by Lientz and Swanson (comparing the software maintenance activities of 487 organizations in Software Maintenance Management) states that only about 25 percent of maintenance is spent on correcting errors. The rest is spent on enhancements. So every hour you spend writing new code may result in two hours of fixing bugs and around seven hours of enhancements (although most of that time is spent on things such as figuring out how to modify the system, testing and deploying).

In other words, high maintenance costs are not typically the result of bad software. In fact, the better your software is, the more maintenance it will probably require, because people tend to use good software and as a result of that the software will have to evolve. The reason for this, the First Law of Software Evolution tells us:

This need for continuing adaptation and evolution is intrinsic to E-type applications and software. It
is, in part, due to the fact that development, installation and operation of the software changes the
application and its operational domain so creating mismatch between the two. Evolution is achieved
in a feedback driven and controlled maintenance process.

So because we keep getting better at making useful software, people start using software more and more. This increasing usage has an ever-growing impact on the operational domains of the software (which will end up being the entire world I suppose) triggering more and more requests for enhancements. The legacy crisis then, ever-increasing software maintenance, is not a crisis that can be averted or reversed: it is an essential property of developing, deploying and operating useful software systems. And as we’ve learned from Fred Brooks, there’s No Silver Bullet for the essential complexities in software engineering.

What this means is that we shouldn’t try to avoid maintenance, because we can’t. Instead we should embed maintenance into our software processes so that development flows directly into it. A good way to ease into maintenance is thinking of initial development as maintenance, except that you’re starting with a system consisting of zero lines of code, no bug reports and the requirements as a list of requests for enhancements. We already use the same practices and the same tools for doing development and maintenance. So instead of having this 90 percent part of all costs being something nobody is prepared for, let’s just pull in the other 10 percent and call it 100 percent software engineering.