Page 257 -

240 Chapter 9 Software evolution

However, problems may arise in situations in which there is a handover from a
development team to a separate team responsible for evolution. There are two poten-
tially problematic situations:

1. Where the development team has used an agile approach but the evolution team
is unfamiliar with agile methods and prefers a plan-based approach. The evolu-
tion team may expect detailed documentation to support evolution and this is
rarely produced in agile processes. There may be no definitive statement of the
system requirements that can be modified as changes are made to the system.

2. Where a plan-based approach has been used for development but the evolution
team prefers to use agile methods. In this case, the evolution team may have to
start from scratch developing automated tests and the code in the system may
not have been refactored and simplified as is expected in agile development. In
this case, some reengineering may be required to improve the code before it can
be used in an agile development process.

Poole and Huisman (2001) report on their experiences in using Extreme Programming
for maintaining a large system that was originally developed using a plan-based
approach. After reengineering the system to improve its structure, XP was used very
successfully in the maintenance process.

9.2 Program evolution dynamics

Program evolution dynamics is the study of system change. In the 1970s and 1980s,
Lehman and Belady (1985) carried out several empirical studies of system change
with a view to understanding more about characteristics of software evolution. The
work continued in the 1990s as Lehman and others investigated the significance of
feedback in evolution processes (Lehman, 1996; Lehman et al., 1998; Lehman et al.,
2001). From these studies, they proposed ‘Lehman’s laws’ concerning system change
(Figure 9.7).
Lehman and Belady claim these laws are likely to be true for all types of large
organizational software systems (what they call E-type systems). These are systems
in which the requirements are changing to reflect changing business needs. New
releases of the system are essential for the system to provide business value.
The first law states that system maintenance is an inevitable process. As the sys-
tem’s environment changes, new requirements emerge and the system must be mod-
ified. When the modified system is reintroduced to the environment, this promotes
more environmental changes, so the evolution process starts again.
The second law states that, as a system is changed, its structure is degraded. The only
way to avoid this happening is to invest in preventative maintenance. You spend time
improving the software structure without adding to its functionality. Obviously, this
means additional costs, over and above those of implementing required system changes.