Learning to Distinguish a Solution from a Problem

Robert L. Glass, Computing Trends

This column is about software maintenance.

Don't quit reading, now! I know that seems like a pretty boring topic. But it's also a vitally important and, more to the point, a totally misunderstood one.

I've been flaming about software maintenance for what seems like several decades. Someone comes out and says something completely stupid about maintenance, and once again I leap into the fray to try to set the record straight.

The Latest Stupidity

InformationWeek is one of my favorite popular-press computing magazines. It doesn't engage in the hype and excess of most of its kin, and I deeply respect it for that. But it was an editorial in the 24 March 2003 issue of IW that set me off this time. In that issue, Bob Evans, IW's editor in chief, starts off on a crusade about what he calls "The Monster in the Basement." As you read on in his editorial, you come to realize that he's talking about legacy software. Not only does he call it a monster, he says "it's strangling innovation and progress," "it's a recipe for atrophy, irrelevance, and ultimately collapse," and the increase in the amount of maintenance over the years is a "dangerous trend."

IW and its editor aren't the first to pick on maintenance, of course. Over the years, it's been a favorite topic for those who see it as an impediment to progress. One notable in the field even paraphrased the "don't automate, obliterate" phrase to apply it to maintenance of legacy code, implying that we ought to throw away the old and rebuild anew. And if you read Evans's editorial carefully, that's what he's advocating as well.

The Buck Stops Here

We in the field seem, in many ways, to reinforce that negative view of maintenance:

• We tend to assign the newest and greenest programmers to maintaining our legacy programs. We assign the best and brightest to new development.
• We eschew the old and the ancient as being out of date. We evolve toward new paradigms and new concepts and are eager to leave the old ones—including old code—behind.
• We teach programmers how to write new programs, but we rarely if ever teach them how to read old ones.
• We talk about software maintenance as if it were a problem and think we should do less of it.
• We evolve and promote methodologies to guide our new software development. We rarely provide tools and techniques, let alone methodologies, to maintenance programmers.
• Once a piece of new software goes into production, we breathe a sign of relief, break up the team, and prepare to move on. We rarely hold postimplementation reviews, gather past project data for future learning experiences, or organize what some academics call experience factories to capitalize on lessons learned.

In short, we generally behave as if the maintenance of legacy software is a Bad Thing, one that we believe would go away if only we would engage in enough Good Acts.

The Facts of Maintenance

All of that is backwards! Somehow, over the few years that software has been a productive, useful discipline, we keep trying to kill the goose that lays more golden eggs than any other in the software barnyard. By disrespecting the maintenance of legacy software, we've turned our collective back on (a) what most people in software do, (b) what most of the money in software is spent on, and (c) our greatest opportunity to please our clients and customers.

But there's more. In disrespecting maintenance, we also ignore some of the most important and perhaps surprising facts in the software field. In Facts and Fallacies of Software Engineering (Addison-Wesley, 2003), I list these three frequently forgotten but fundamental facts about maintenance:

• Maintenance typically consumes 40 to 80 percent of software costs. So, it's probably software's most important lifecycle phase.
• Enhancement is responsible for roughly 60 percent of software maintenance costs. Error correction is roughly 17 percent. So, software maintenance is largely about adding new capability to old software, not fixing it.
• Better software engineering development leads to more maintenance, not less. (To completely understand this counterintuitive fact, you'll have to read the book! But basically, this concerns backlogs of maintenance activities such that, if a maintenance task takes less time, you can address more of the backlog.)

Given those facts, I conclude that maintenance is a solution, not a problem (another frequently forgotten but fundamental fact, and the rallying cry I'd like you to take away from this column!). And, if it's a solution, we should be doing more of it, not less.

History Repeats Itself

Let me tell you a little story about maintenance, one that's very personal and yet generalizable to the whole field. One of software's most articulate spokespersons, when he was fresh out of college, was asked by his company to discard an old, legacy software product and produce a new version of it. He accepted the assignment with alacrity, looking forward to putting to work all those gleaming new concepts he had learned in computing academe.

As time festered on, he realized to his horror that the task was approaching insurmountability. No one knew all the requirements for the old product (those who did had left the company long ago). No one knew enough about the old code's design to reengineer it to recreate those requirements. No one seemed to understand how much work had gone into the old product, so the expectation existed that with new and gleaming techniques, the re-creation would somehow take an insignificant amount of time. And, as time passed, no one in management held much patience for the mushrooming task of discarding the old and re-creating it.

In the end, the new product was thrown away, a dead loss, because it couldn't be made to do what the old product had done. The old, legacy product was placed back in maintenance, soldiering productively on into the future.

If that were the only such story in software history, it would make an interesting anecdote, but nothing more. But I've seen this story repeated time after time. Brilliant software engineers such as David Parnas and his team were unable to reproduce, using new techniques, the software functionality for the A-7 aircraft on a sufficiently timely basis. Hordes of software specialists at a leading banking institution were unable to produce a new, enhanced version of their old and seemingly obsolete main product because they couldn't wrap their arms around its complex functionality. In my view, some of the worst disasters in computing history have involved trying to rebuild those old legacy systems.

Conclusion

Now, is legacy software really "the monster in the basement"? Or is it, instead, the silent majority of software work, quietly cranking out valid, useful results, decade after decade?

You know what my answer is.

Robert L. Glass is editor emeritus of Elsevier's Journal of Systems and Software, the publisher and editor of the Software Practitioner newsletter, and a certified "premier curmudgeon of software practice." Contact him at rglass@indiana.edu; he'd be pleased to hear from you.