For those of us working in software development and studying it, there's a shortage of comprehensive studies to refer to, too little data that developers and managers can trust and draw useful conclusions from. Even worse, too much of the research that we do have is out of date or derivative. A small number of early, foundational studies and the data that they came up with are referenced, reused, repackaged and reinterpreted in more modern contexts by subsequent researchers – we keep going over the same old ground.

This is especially the case for software maintenance. One of these foundational studies in software maintenance, one of the most widely referenced, was done by a team at UCLA led by Benet P. Lientz and E. Burton Swanson back in the late 1970s. They surveyed software maintenance practices at 487 companies, and found that companies spent their time on maintenance activities as follows:

Perfective maintenance - new functional or nonfunctional requirements: 65%
Corrective maintenance - fixing bugs: 17%
Adaptive maintenance - keeping up with changes in the environment: 18%

But wait a minute. Another source quotes the same study of “nearly 500 data processing groups” differently:

Perfective maintenance: 51%
Adaptive maintenance: 24%
Corrective maintenance: 22%
Preventive maintenance: 3%

Sorry, that’s not right. The study was in 1978, not 1980, it was only 69 companies, and it found:

Corrective maintenance: 17.4%
Adaptive maintenance: 18.2%
Perfective maintenance: 60.3%
Other: 4.1%

No, that’s not right either. It was in 1980, there were 487 companies, but the numbers are:

Corrective maintenance: slightly more than 20%
Adaptive maintenance: slightly less than 25%
Perfective maintenance: over 50%
Preventive maintenance: only 5%

This inconsistency was starting to bug me, so I ordered the book detailing the original analysis work, Software Maintenance Management: a Study of the Maintenance of Computer Application Software in 487 Data Processing Organizations by Lientz and Swanson, published in 1980.

A couple of weeks later thanks to Amazon, I had the answer. It turns out that there were two studies. Lientz and Swanson’s analysis started with a pilot study of 69 organizations. This pilot found that on average, 60% of maintenance was spent in enhancements, better documentation and more efficient coding – what Lientz and Swanson called “perfective maintenance”. And that the biggest, most important problems that organizations faced were management problems, not technical problems: trying to find ways to manage escalating customer demands for enhancements and extensions to software.

Not satisfied with the smaller study, they conducted a more detailed study of 487 IT organizations starting in late 1977. The key findings included that on average, development and systems staff spent half of their time on maintenance. The larger the company, the more time was spent on maintenance. Maintenance effort, on average, was broken out as follows:

Corrective Maintenance

Emergency fixes: 12.4%
Routine debugging: 9.3%
21.7%

Adaptive Maintenance

Accommodating changes to data inputs and files: 17.4%
Accommodating changes to hardware and system software: 6.2%
23.6%

Perfective Maintenance

Customer enhancements: 41.8%
Improvements to documentation: 5.5%
Optimization: 4.0%
51.3%

(Not) Preventive Maintenance

Other: 3.4%
3.4%

The most severe maintenance problems, according to maintenance managers:

• Poor quality application system documentation
• Excessive demand from customers for changes
• Competing demands for maintenance personnel time
• Difficulty meeting schedule commitments
• Inadequate training of user personnel
• Turnover in the user organization

The major problem areas for maintenance managers, from the study’s perspective:

• Customers don’t understand how the system works and what they need it to do: lack of user understanding, lack of user training
• Programmer effectiveness: low productivity, low motivation, low skill levels
• Low quality of the system being maintained: inadequate design specs, quality of original code, quality of documentation
• Programmer availability: competing demands for programmer time

So there we are: the state of software maintenance in 1977. How much of this has changed, really, since then? And why don’t we have better numbers, newer data, on something that most of us will spend most of our careers working on?