Most managers or project leaders responsible for the maintenance and enhancement of existing applications feel frustration. They know that if they could just get the new version of their program finished, they could solve lots of problems. But responding to those problems can be what prevents the new version from being finished!
Why Is Maintenance Such a Problem?
Most of us are rewarded for putting our programs into production use. The rewards are greatest where there is a large improvement in the work the computer is doing for the user. Similarly, the punishments for not getting new software deployed can be large and painful. On the other hand, the pressures to update an old application can be great: just look at the year 2000 hoopla!
If you're like most of us, your boss remembers when you promised to have the new software ready. He (or she) is not so likely to remember the time spent updating the old application to handle an upgrade in operating system or network software.
In addition to the external (boss, company, market) pressure, most programmers get psychic rewards from seeing our programs put to use, but find fixing bugs and/or making small improvements psychically unrewarding, for a variety of reasons:
- Lack of control -- maintenance is usually reactive, and isn't conducive to the sort of planning that programmers like.
- Old technology -- it's less "sexy".
- Code that someone else wrote.
- Poorly written code (even if you wrote it in an earlier day!).
- Start-up time to become familiar with the code (even if you wrote it!).
In short: no fun.
Why Does Maintenance Take So Much Time?
In addition to programmer reluctance, the following specific problems all contribute to the high cost of maintenance:
Unfamiliar Code:
When doing maintenance, the programmer is
most often working on unfamiliar code, which s/he either didn't write,
or wrote so long ago that s/he doesn't remember it. The code, written
in an unfamiliar formatting/indenting style,
is actually hard for the
programmer to read. Both the unfamiliarity and the reading difficulty
make it hard for the programmer to understand the overall structure
and design of the program. Since the programmer doesn't have
familiarity with the code or design,
the coding decisions s/he makes take longer and are
more likely to be wrong (buggy) or inappropriate.
Changes made by programmers who are unfamiliar with the code are much more likely to be patches -- small sections of code that deal with the symptoms of an issue, rather than the root causes.
Bad/missing Documentation:
It's rare for an existing system to
be well documented. This documentation may be written, but
more likely is stored in the
head of the original program author:
"Go ask Joe, he wrote that."
At many organizations, old application documentation
simply doesn't exist. Even worse,
the documentation may exist, but be out of date and misleading.
This missing or bad documentation aggrevates the problems caused
by unfamiliar code.
Fragile Code:
Even if a program wasn't fragile to start with,
after years of maintenance by unfamiliar programmers, a program becomes
fragile. A fragile program is one where there are numerous and
undocumented
interconnections, so that when an improvement is made in one area, bugs
are introduced in other-- sometimes seemingly unrelated-- areas of the
program. Programs become increasing fragile as they are "patched" over
time. Each patch weakens the structure of the program, thereby
increasing the interconnections and making it harder to understand.
Induced Bugs:
New bugs created while making changes to a program
are one of the major sources of maintenance headaches. If you're lucky,
the bugs are found during testing, so they just add time to the
project. Sometimes, however, these induced bugs make it into production,
often precipitating a new crisis.
These induced bugs arise from several sources:
Programmer misunderstandings -- the programmer just didn't understand the structure of the program well enough when making the change.
Hidden interconnections -- inappropriate interconnections (often the result of previous maintenance) are hidden "land mines" for the maintenance programmer. Each of these interconnections creates additional constraints on any future changes, and these constraints are neither documented nor logically follow from the program structure. As a result, the maintenance programmer has little chance of preventing a bug when making a change involving a hidden interconnection.
Incomplete testing -- maintenance programmers often fail to test fully all the parts of a program affected by a change, for two reasons: first, they may not understand the program structure well enough to know all the areas affected. Second, they may find it too difficult to test a particular part of a program, particularly if it is a deeply nested or widely called routine.
New Engineer Startup Time:
As programs get bigger and bigger,
and as the program structure becomes more and more obscured by changes over
time,
it takes longer and longer to bring a new engineer up to speed -- to reach
the point where s/he is creating a day's worth of results for a day's
worth of work.
Many companies report delays of three to six months before a new
or reassigned engineer reaches full productivity.
The reasons include hard-to-understand code, missing or incomplete
documentation, and fear of making a mistake.
Fear of Making Mistakes:
Faced with all these problems and with
mounting pressure to get an issue resolved quickly, programmers doing
maintenance often chose the smallest possible change that resolves
an issue. The main reason for this is the fear
that more induced bugs will be created as more code is changed,
and that "doing it right" will
take too long, both in understanding time and debugging time.
Unfortunately, choosing the smallest possible change, while perhaps a valid way to resolve the current issue promptly, often leads to future maintenance problems. The smallest change is usually just a patch, and serves to weaken the program's structure, increase inappropriate interconnections, and increase a program's fragility.