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