Page 262 -

9.3 Software maintenance 245

Legacy systems

Legacy systems are old systems that are still useful and are sometimes critical to business operation. They may
be implemented using outdated languages and technology or may use other systems that are expensive to
maintain. Often their structure has been degraded by change and documentation is missing or out of date.
Nevertheless, it may not be cost effective to replace these systems. They may only be used at certain times
of the year or it may be too risky to replace them because the specification has been lost.
http://www.SoftwareEngineering-9.com/Web/LegacySys/

the lifetime of the system. This assumes that a percentage increase in development
costs results in a comparable percentage decrease in overall system costs.
These estimates are hypothetical but there is no doubt that developing software to
make it more maintainable is cost effective, when the whole life costs of the software
are taken into account. This is the rationale for refactoring in agile development.
Without refactoring, the code becomes more and more difficult and expensive to
change. However, in plan-based development, the reality is that additional invest-
ment in code improvement is rarely made during development. This is mostly due to
the ways most organizations run their budgets. Investing in maintainability leads to
short-term cost increases, which are measurable. Unfortunately, the long-term gains
can’t be measured at the same time so companies are reluctant to spend money for an
unknown future return.
It is usually more expensive to add functionality after a system is in operation than
it is to implement the same functionality during development. The reasons for this are:

1. Team stability After a system has been delivered, it is normal for the develop-
ment team to be broken up and for people to work on new projects. The new
team or the individuals responsible for system maintenance do not understand
the system or the background to system design decisions. They need to spend
time understanding the existing system before implementing changes to it.
2. Poor development practice The contract to maintain a system is usually separate
from the system development contract. The maintenance contract may be given
to a different company rather than the original system developer. This factor,
along with the lack of team stability, means that there is no incentive for a devel-
opment team to write maintainable software. If a development team can cut cor-
ners to save effort during development it is worthwhile for them to do so, even if
this means that the software is more difficult to change in the future.
3. Staff skills Maintenance staff are often relatively inexperienced and unfamiliar with
the application domain. Maintenance has a poor image among software engineers.
It is seen as a less-skilled process than system development and is often allocated to
the most junior staff. Furthermore, old systems may be written in obsolete program-
ming languages. The maintenance staff may not have much experience of develop-
ment in these languages and must learn these languages to maintain the system.