practice

Doi: 10.1145/1592761.1592777

Article development led by queue.acm.org

Long considered an afterthought, software
maintenance is easiest and most effective
when built into a system from the ground up.
BY PauL stachouR anD DaViD coLLieR-BRoWn
You Don’t
Know
Jack about
software
maintenance
eVerYoNe KNoWs MaiNTeNaNCe is difficult and
boring, and therefore avoids doing it. It doesn’t help
that many pointy-haired bosses (PHBs) say things like:
“no one needs to do maintenance—that’s a waste of
time.”
“Get the software out now; we can decide what its
real function is later.”
“Do the hardware first, without thinking about the
software.”
“Don’t allow any room or facility for expansion. You
can decide later how to sandwich the changes in.”
These statements are a fair description of development

during the last boom, and not too far from what many of us are doing today. This is not a good thing: when you hit the first bug, all the time you may have “saved” by ignoring the need to do maintenance will be gone.

During a previous boom, General Electric designed a mainframe that it claimed would be sufficient for all the computer uses in Boston, and would never need to be shut down for repair or for software tweaks. The machine it eventually built wasn’t nearly big enough, but it did succeed at running continuously without need for hardware or software changes.

Today we have a distributed network of computers provided by thousands of businesses, sufficient for everyone in at least North America, if not the world. Still, we must keep shutting down individual parts of the network to repair or change the software. We do so because we’ve forgotten how to do software maintenance.

What is software maintenance?

Software maintenance is not like hardware maintenance, which is the return of the item to its original state. Software maintenance involves moving an item away from its original state. It encom-passes all activities associated with the process of changing software. That includes everything associated with “bug fixes,” functional and performance enhancements, providing backward compatibility, updating its algorithm, covering up hardware errors, creating user-interface access methods, and other cosmetic changes.

In software, adding a six-lane automobile expressway to a railroad bridge is considered maintenance— and it would be particularly valuable if you could do it without stopping the train traffic.

Is it possible to design software so it can be maintained in this way? Yes, it is. So, why don’t we?

PhotograPh by raLPh grUne WaLD

the four horsemen of the apocalypse There are four approaches to software