Programming integrated over time: evolution, maintenance and the definition of engineering

The first of the ten units sets the time horizon every later one works within. The claim is that the time horizon separates software engineering from programming, and that the size of the system does not: the cost of future change defines the discipline, its characteristic failure is a system that can no longer be changed, and that failure is something design can address, because change accumulates in structures never built for it.

Software engineering was named at a conference about size. At Garmisch in October 1968, more than fifty people spent five days on the report's problems of scale. Large projects were missing their schedules and their specifications. The failures looked managerial rather than technical (Naur and Randell, 1969). On that reading, the discipline exists to build big systems.

A working paper in the same report shifts the emphasis. Gillette writes on maintainable software. He states that maintenance cost frequently exceeds development cost, and that maintaining a delivered system is an unending process which lasts for the life of the machine (Naur and Randell, 1969). The expensive work happens after the first release, under a clock nobody set at the start.

The normal case is change, not construction

Lehman's programme states this as a regularity rather than an impression. He worked from quantitative studies of how a number of large systems changed. From those studies he concluded that evolutionary pressure produces never ending maintenance activity, and he formulated laws of program evolution (Lehman, 1980). He also set out the FEAST project's programme to test them, and he presented them as the expected behaviour of a feedback system. The anomaly is the system that stops.

The systems behind those studies were IBM's OS/360 and its successive releases. The laws therefore came from one lineage of one product family, not from a sample of the industry (Lehman, 1996). As a program evolves, its complexity increases unless work maintains or reduces it. Every change already made therefore raises the cost of the next one (Lehman, 1980).

Parnas makes the failure state precise. Programs age, he argues, not because they are old. They age because change after change accumulates in structures never designed for it. Deciding what is likely to change is therefore the core of design. He adds the profession's test. Engineering will deserve its name when we stop treating the first release as the end, and when we attend to the long-term health of the product (Parnas, 1994). The worst outcome is a next change that cannot be made. Its users may include older users and disabled people who cannot move to a replacement.

A vocabulary that makes the cost visible

Swanson supplied the classification on which later measurement depends. He separates three kinds of work. Corrective maintenance answers processing, performance or implementation failures. Adaptive maintenance answers changes in the data or processing environment. Perfective maintenance removes inefficiency, improves performance or improves maintainability (Swanson, 1976). He adopts an earlier trade journal's metaphor and calls maintenance an iceberg, one whose shape resists measurement. Citing a 1973 survey, he reports that almost 40 per cent of software effort in Great Britain went into it.

The taxonomy is not bookkeeping. It makes the claim testable. It separates work that would disappear if the software were perfect from work that exists because the world moved. A team that reports one maintenance number cannot tell defects from a shifting platform, or from its own deferred improvements. The three have different remedies.

Evolution over a lifetime, and how thin the base is

The empirical base is thinner than the vocabulary suggests. Swanson wrote in 1976 that we know very little about maintenance, and that it remained an iceberg. Bennett and Rajlich (2000) repeated the complaint a quarter of a century later. They identified a widening gap between the cost of maintaining systems and the effort spent studying how. They argued that evolution is the dominant activity of most industrial software organisations. Their roadmap proposes a service-based view of software in place of a product view.

The best attempt to close the gap with data is Kemerer and Slaughter (1999). They collected, coded and analysed more than 25,000 change events across 23 commercial software systems over a 20-year period. They adapted sequence methods from social psychology to identify the phases a system travels through. Researchers can therefore study evolution longitudinally, at whole-product scale, with methods that detect a change of phase and not only of size.

Godfrey and German (2008) describe the shift this represents, from analysing static snapshots to modelling how systems change across their lifetimes. They connect it to Lehman's laws and to Bennett and Rajlich's staged lifecycle model. Rajlich (2014) states the consequence. Agile, iterative, open-source and inner-source processes place development inside a running system, so the bulk of software development now happens during evolution.

Contested question: are the laws laws, and is evolution the bulk of the work?

Two disagreements run through this literature.

The first is whether Lehman's laws are regularities at all. Lehman (1980, 1996) presents them as the expected behaviour of a feedback system. Godfrey and German (2008) treat them, with the staged lifecycle model, as the field's organising theory. The opposing position is empirical, and it comes from the field's own audits. Herraiz, Rodriguez, Robles and Gonzalez-Barahona (2013) reviewed the literature systematically. They report that controversial studies about the laws' validity are common. They report that nobody had revised the laws for about fifteen years. They report that questions about their validity remain open. An observation from one lineage of large systems is a strong hypothesis and a weak law.

The project Lehman launched to test the laws reported a second lineage rather than a second test. FEAST's first data set was Logica's FW banking transaction system, with about one hundred user sites and twenty three releases. Lehman presented it as preliminary, while the project's formal work awaited its start (Lehman, 1996).

The second concerns the size of the maintenance burden. Bennett and Rajlich (2000) call evolution the dominant activity of most industrial organisations. Swanson's (1976) taxonomy makes such a figure partly definitional. Perfective work includes enhancements that a project might count as development, so classification can manufacture a large maintenance share rather than discover it. Swanson asks for measures standardised across organisations, so that the field can assess the iceberg's shape.

One kind of evidence would settle both. It is a set of systems wide enough to test a law across contexts, with the change categories declared in advance and applied identically. The evidence must follow those systems long enough for phases to appear, and report them so that a failed prediction is visible. Kemerer and Slaughter (1999) supply the longitudinal half. Nobody has run the multi-organisation half. Until somebody does, the defensible position is narrower than the rhetoric. Change is demonstrably the normal case, and its cost is the right subject for engineering, but no settled law describes how it grows.

What to do while the dispute is open

The evidence on the two sides is unequal. That change is the normal case rests on decades of case studies, while that it follows a law rests on one product lineage and an unfinished test programme. The strongest objection to this unit's thesis is that it mistakes a description for a programme. Brooks (1987) separates the essential difficulties of software from the accidental ones that tools can remove. The essential difficulties are complexity, conformity, changeability and invisibility. He concludes that no single development in technology or management promises an order-of-magnitude improvement in productivity, reliability or simplicity. Changeability is on that essential list, which supports the thesis that change is permanent. The same argument denies that any discipline removes the cost. While the dispute is open, a designer should budget each change against a maintenance estimate, and treat the next change as a first-class deliverable rather than a residual. Brooks had also shown at project scale that adding people to a late project makes it later (Brooks, 1975). The discipline's competence is managing change, not abolishing it.

Where the argument is heading

The field moves from treating evolution as the residue after development to treating it as the main event. Rajlich (2014) records that the process models of the last two decades all moved development inside a running system. Godfrey and German (2008) set out the open challenges of modelling change across a lifetime. Herraiz and others (2013) close with the challenges they expect in the coming years. Sommerville (2015) shows the shift reaching the syllabus, where evolution and maintenance are core rather than residual.

The sources this unit rests on

• Naur, P. and Randell, B. (1969). Software Engineering: Report on a Conference Sponsored by the NATO Science Committee, Garmisch, Germany, 7-11 October 1968. Brussels: NATO Scientific Affairs Division. http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF Reports the 1968 NATO conference that coined the term software engineering, where large projects were judged to be failing for reasons of scale and management. Its working paper by Gillette states that maintenance cost frequently exceeds development cost and lasts for the life of the machine, the unit's earliest evidence for reading the discipline through time.
• Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Reading, MA: Addison-Wesley. https://archive.org/details/mythicalmanmonth00broo Argues from the experience of managing OS/360 that adding people to a late project makes it later, because communication cost grows faster than team size, and that conceptual integrity is a design's most important property. The unit's project-scale counterweight: the dominant costs are human and conceptual, and no method abolishes them.
• Brooks, F. P. (1987). No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer 20(4), 10-19. doi:10.1109/MC.1987.1663532 Separates the essential difficulties of software, complexity, conformity, changeability and invisibility, from the accidental ones tools can remove, and denies that any single development promises an order-of-magnitude improvement within a decade. Changeability is essential, which supports the thesis and denies that any method removes the cost.
• Lehman, M. M. (1980). Programs, Life Cycles, and Laws of Software Evolution. Proceedings of the IEEE 68(9), 1060-1076. doi:10.1109/PROC.1980.11805 Formulates laws of program evolution from quantitative studies of how a number of large systems changed, concluding that evolutionary pressure produces never ending maintenance activity. A delivered system's normal state is continuous change, not stability, which is the unit's central regularity.
• Lehman, M. M. (1996). Laws of Software Evolution Revisited. In Montangero, C. (ed.) Software Process Technology, EWSPT 1996, Lecture Notes in Computer Science 1149. Berlin: Springer, 108-124. doi:10.1007/BFb0017737 Restates the laws and describes the FEAST project's programme to test them, presenting them as the expected behaviour of a feedback system rather than empirical coincidences. It turns the observation that systems change into a mechanism, which the unit's causal claim needs.
• Parnas, D. L. (1994). Software ageing. In Proceedings of the 16th International Conference on Software Engineering (ICSE 1994). Los Alamitos, CA: IEEE Computer Society Press, 279-287. doi:10.1109/ICSE.1994.296790 Argues that programs age not because they are old but because successive changes accumulate in structures not designed for them, so deciding what is likely to change is the core of design. It supplies the unit's failure state and its prescription, that engineering will deserve its name when it attends to long-term product health.
• Swanson, E. B. (1976). The Dimensions of Maintenance. In Proceedings of the 2nd International Conference on Software Engineering (ICSE 1976). Los Alamitos, CA: IEEE Computer Society Press, 492-497. https://web.archive.org/web/20220617124141/http://www.mit.jyu.fi/ope/kurssit/TIES462/Materiaalit/Swanson.pdf Proposes the taxonomy of corrective, adaptive and perfective maintenance and warns that maintenance is an iceberg whose shape resists measurement; citing a 1973 survey, it reports that almost 40 per cent of software effort in Great Britain went into maintenance. It makes the cost of future change measurable, and cautions that the figure depends partly on classification.
• Godfrey, M. W. and German, D. M. (2008). The Past, Present, and Future of Software Evolution. In 2008 Frontiers of Software Maintenance. Piscataway, NJ: IEEE, 129-138. doi:10.1109/FOSM.2008.4659256 Surveys research on software evolution, distinguishes it from maintenance, and discusses Lehman's laws with the staged lifecycle model of Bennett and Rajlich. It finds the field has moved from analysing static snapshots to modelling change across a lifetime, the programme the unit claims as engineering's subject.
• Herraiz, I., Rodriguez, D., Robles, G. and Gonzalez-Barahona, J. M. (2013). The Evolution of the Laws of Software Evolution: A Discussion Based on a Systematic Literature Review. ACM Computing Surveys 46(2), Article 28. doi:10.1145/2543581.2543595 Reviews the literature on the laws of software evolution systematically and reports that controversial studies about their validity are common, that the laws had not been revised for about fifteen years, and that key questions remain open. It is why the laws are treated here as a contested regularity, not settled knowledge.
• Bennett, K. H. and Rajlich, V. T. (2000). Software Maintenance and Evolution: A Roadmap. In Proceedings of the Conference on the Future of Software Engineering (ICSE 2000). New York: ACM, 73-87. doi:10.1145/336512.336534 Sets the research agenda for maintenance and evolution, identifies a widening gap between the cost of maintaining systems and the effort spent studying how, argues that evolution is the dominant activity of most industrial software organisations, and proposes a service-based model of software in place of a product view.
• Rajlich, V. (2014). Software Evolution and Maintenance. In Proceedings of the on Future of Software Engineering (FoSE 2014). New York: ACM, 133-144. doi:10.1145/2593882.2593893 Argues that constant change, triggered by evolving requirements, technologies and stakeholder knowledge, constitutes software evolution, and that because agile, iterative, open-source and inner-source processes place development inside a running system, the bulk of software development now happens during evolution.
• Kemerer, C. F. and Slaughter, S. (1999). An Empirical Approach to Studying Software Evolution. IEEE Transactions on Software Engineering 25(4), 493-509. doi:10.1109/32.799945 Collects, codes and analyses more than 25,000 change events across 23 commercial software systems over a 20-year period, adapting sequence methods from social psychology to identify the phases a system travels through. It shows that the cost of change can be measured across a lifetime rather than asserted from one case.
• Sommerville, I. (2015). Software Engineering. 10th edition. Boston, MA: Pearson. https://www.pearson.com/en-us/subject-catalog/p/Sommerville-Software-Engineering-10th-Edition/P200000003258/9780137503148 The standard textbook organises software engineering around the processes and techniques for producing reliable systems over their lifetimes and treats evolution and maintenance as core rather than residual. It shows the unit's thesis reaching the syllabus, evidence about the field's self-description rather than about systems.