Program evolution dynamics is the study of system change. In the 1970s and 1980s, Lehman and Belady, carried out several empirical studies of system change (Lehman and Belady, 1985) 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. These are shown in the following table.
| Law | Description | |
|---|---|---|
| 1: Continuing change | A program that is used in a real-world environment must necessarily change or else become progressively less useful in that environment. | |
| 2: Increasing complexity | As an evolving program changes its structure tends to become more complex. Extra resources must be devoted to preserving and simplifying the structure. | |
| 3: Large program evolution | Program evolution is a self-regulating process. System attributes such as size; time between releases; the number of reported errors is approximately invariant for each system release. | |
| 4: Organizational stability | Over a program’s lifetime its rate of development is approximately constant and independent of the resources devoted to system development. | |
| 5: Conservation of familiarity | Over the lifetime of a system the incremental change in each release is approximately constant. | |
| 6: Continuing growth | The functionality offered by systems has to continually increase to maintain user satisfaction. | |
| 7: Declining quality | The quality of systems will decline unless they are modified to reflect changes in their operational environment. | |
| 8: Feedback system | Evolution processes incorporate multi-agent and multi-loop feedback systems. You have to treat them as feedback systems to achieve significant product improvement. |
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 system’s environment changes, new requirements emerge and the system must be modified. When the modified system is re-introduced 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.
The third law is, perhaps, the most interesting and contentious of Lehman’s laws. It suggests that large systems have a dynamic of their own that is established at an early stage in the development process. This determines the gross trends of the system maintenance process and limits the number of possible system changes. Lehman and Belady suggest that this law is a consequence of structural factors that influence and constrain system change, and organizational factors that affect the evolution process.
The structural factors that affect the third law come from the complexity of large systems. As you change and extend a program, its structure tends to degrade. This is true of all types of system (not just software) and it occurs because you are adapting a structure intended for one purpose for a different purpose. This degradation, if unchecked, makes it more and more difficult to make further changes to the program. Making small changes reduces the extent of structural degradation and so lessens the risks of causing serious system dependability problems. If you try and make large changes, there is a high probability that these will introduce new faults. These then inhibit further program change.
The organizational factors that affect the third law reflect the fact that large systems are usually produced by large organizations. These companies have internal bureaucracies that set the change budget for each system and control the decision-making process. Companies have to make decisions on the risks and value of the changes and the costs involved. Such decisions take time to make and, sometimes, it takes longer to decide on the changes to be made than change implementation. The speed of the organization’s decision-making processes therefore governs the rate of change of the system.
Lehman’s fourth law suggests that most large programming projects work in a ‘saturated’ state. That is, a change to resources or staffing has imperceptible effects on the long-term evolution of the system. This is consistent with the third law, which suggests that program evolution is largely independent of management decisions. This law confirms that large software development teams are often unproductive because communication overheads dominate the work of the team.
Lehman’s fifth law is concerned with the change increments in each system release. Adding new functionality to a system inevitably introduces new system faults. The more functionality added in each release, the more faults there will be. Therefore, a large increment in functionality in one system release means that this will have to be followed by a further release in which the new system faults are repaired. Relatively little new functionality should be included in this release. This law suggests that you should not budget for large functionality increments in each release without taking into account the need for fault repair.
The first five laws were in Lehman’s initial proposals; the remaining laws were added after further work. The sixth and seventh laws are similar and essentially say that users of software will become increasingly unhappy with it unless it is maintained and new functionality is added to it. The final law reflects the most recent work on feedback processes, although it is not yet clear how this can be applied in practical software development.
Lehman’s observations seem generally sensible. They should be taken into account when planning the maintenance process. It may be that business considerations require them to be ignored at any one time. For example, for marketing reasons, it may be necessary to make several major system changes in a single release. The likely consequences of this are that one or more releases devoted to error repair are likely to be required. You often see this in personal computer software when a major new release of an application is often quickly followed by a bug repair update.
References
Lehman, M. M. (1996). ‘Laws of Software Evolution Revisited’. Proc. European Workshop on Software Process Technology (EWSPT’96), Springer-Verlag. 108-24.
Lehman, M. M. and Belady, L. (1985). Program Evolution: Processes of Software Change. London: Academic Press.
Lehman, M. M., Perry, D. E. and Ramil, J. F. (1998). ‘On Evidence Supporting the FEAST Hypothesis and the Laws of Software Evolution’. Proc. Metrics’98, Bethesda. Maryland: IEEE Computer Society Press. 84-8.
Lehman, M. M., Ramil, J. F. and Sandler, U. (2001). ‘An Approach to Modelling Long-term Growth Trends in Software Systems’. Proc. Int. Conf. on Software Maintenance, Florence, Italy: 219-28.