112IEEE SOFTWARE Published by the IEEE Computer Society 0740-7459/04/$20.00 © 2004 IEEEloyal oppositionEditor: Robert L. Glass ■ Computing Trends ■ [email protected] column is about software maintenance.Don’t quit reading, now! I know thatseems like a pretty boring topic. But it’salso a vitally important and, more to thepoint, a totally misunderstood one.I’ve been flaming about software mainte-nance for what seems like several decades. Some-one comes out and says something completelystupid about maintenance, and once again I leapinto the fray to try to set the record straight.The latest stupidityInformationWeek is one of myfavorite popular-press computingmagazines. It doesn’t engage in thehype and excess of most of its kin,and I deeply respect it for that. Butit was an editorial in the 24 March2003 issue of IW that set me offthis time. In that issue, Bob Evans,IW’s editor in chief, starts off on acrusade about what he calls “TheMonster in the Basement.” As you read on inhis editorial, you come to realize that he’s talk-ing about legacy software. Not only does hecall it a monster, he says “it’s strangling inno-vation and progress,” “it’s a recipe for atro-phy, irrelevance, and ultimately collapse,” andthe increase in the amount of maintenanceover the years is a “dangerous trend.”IW and its editor aren’t the first to pick onmaintenance, of course. Over the years, it’sbeen a favorite topic for those who see it as animpediment to progress. One notable in thefield even paraphrased the “don’t automate,obliterate” phrase to apply it to maintenanceof legacy code, implying that we ought tothrow away the old and rebuild anew. And ifyou read Evans’s editorial carefully, that’swhat he’s advocating as well.The buck stops hereWe in the field seem, in many ways, to re-inforce that negative view of maintenance:■ We tend to assign the newest and greenestprogrammers to maintaining our legacyprograms. We assign the best and brightestto new development.■ We eschew the old and the ancient as beingout of date. We evolve toward new paradigmsand new concepts and are eager to leave theold ones—including old code—behind.■ We teach programmers how to write newprograms, but we rarely if ever teach themhow to read old ones.■ We talk about software maintenance as if itwere a problem and think we should do lessof it.■ We evolve and promote methodologies toguide our new software development. Werarely provide tools and techniques, let alonemethodologies, to maintenance programmers.■ Once a piece of new software goes into pro-duction, we breathe a sign of relief, breakup the team, and prepare to move on. Werarely hold postimplementation reviews,gather past project data for future learningexperiences, or organize what some academ-ics call experience factories to capitalize onlessons learned.Learning to Distinguish aSolution from a ProblemRobert L. Glass… in which I make a plea for more respect for software maintenance and software maintainersContinued on p. 111May/June 2004IEEE SOFTWARE 111LOYAL OPPOSITIONIn short, we generally behave as ifthe maintenance of legacy software is aBad Thing, one that we believe wouldgo away if only we would engage inenough Good Acts.The facts of maintenanceAll of that is backwards! Somehow,over the few years that software hasbeen a productive, useful discipline, wekeep trying to kill the goose that laysmore golden eggs than any other in thesoftware barnyard. By disrespecting themaintenance of legacy software, we’veturned our collective back on (a) whatmost people in software do, (b) whatmost of the money in software is spenton, and (c) our greatest opportunity toplease our clients and customers.But there’s more. In disrespectingmaintenance, we also ignore some ofthe most important and perhaps sur-prising facts in the software field. InFacts and Fallacies of Software Engi-neering (Addison-Wesley, 2003), I listthese three frequently forgotten butfundamental facts about maintenance:■ Maintenance typically consumes 40to 80 percent of software costs. So,it’s probably software’s most impor-tant lifecycle phase.■ Enhancement is responsible forroughly 60 percent of softwaremaintenance costs. Error correctionis roughly 17 percent. So, softwaremaintenance is largely about addingnew capability to old software, notfixing it.■ Better software engineering devel-opment leads to more maintenance,not less. (To completely understandthis counterintuitive fact, you’llhave to read the book! But basically,this concerns backlogs of mainte-nance activities such that, if a main-tenance task takes less time, you canaddress more of the backlog.)Given those facts, I conclude thatmaintenance is a solution, not a prob-lem (another frequently forgotten butfundamental fact, and the rallying cryI’d like you to take away from this col-umn!). And, if it’s a solution, weshould be doing more of it, not less.History repeats itselfLet me tell you a little story aboutmaintenance, one that’s very personaland yet generalizable to the wholefield. One of software’s most articulatespokespersons, when he was fresh outof college, was asked by his companyto discard an old, legacy softwareproduct and produce a new version ofit. He accepted the assignment withalacrity, looking forward to putting towork all those gleaming new conceptshe had learned in computing academe.As time festered on, he realized tohis horror that the task was approach-ing insurmountability. No one knew allthe requirements for the old product(those who did had left the companylong ago). No one knew enough aboutthe old code’s design to reengineer it torecreate those requirements. No oneseemed to understand how much workhad gone into the old product, so theexpectation existed that with new andgleaming techniques, the re-creationwould somehow take an insignificantamount of time. And, as time passed,no one in management held much pa-tience for the mushrooming task of dis-carding the old and re-creating it.In the end, the new product wasthrown away, a dead loss, because itcouldn’t be made to do what the oldproduct had done. The old, legacy prod-uct was placed back in maintenance, sol-diering productively on into the future.If that were the only such story insoftware history, it would make an in-teresting anecdote, but nothing more.But I’ve seen this story repeated timeafter time. Brilliant software engineerssuch as David Parnas and his teamwere unable to