On the evolution of Lehman's Laws

In this brief paper, we honour the contributions of the late Prof. Manny Lehman to the study of software evolution. We do so by means of a kind of evolutionary case study: First, we discuss his background in engineering and explore how this helped to shape his views on software systems and their development; next, we discuss the laws of software evolution that he postulated based on his industrial experiences; and finally, we examine how the nature of software systems and their development are undergoing radical change, and we consider what this means for future evolutionary studies of software. I. LEHMAN’S INTELLECTUAL JOURNEY Meir “Manny” Lehman did not follow a traditional career path for an academic. His father died when he was young, and Lehman had to enter the workforce to help support his family instead of attending university.1 He got his first job in 1941 “performing maintenance on” (i.e., repairing) civilian radios; in England at the height of the second world war, this was a job of real importance. For the most part, his work involved replacing the components that the “tester” (or “debugger”, in software engineering parlance) had determined to be problematic. He found the work repetitive and dull; he decided that he really wanted to be a tester. One day, his foreman called in sick and Lehman was allowed to do testing, but when the foreman returned, Lehman was told to go back to maintenance. When Lehman protested that he thought he had been promoted, the foreman replied “Well, you’re not paid to think” [9]. Lehman would later dedicate a large portion of his life to demonstrate that those who do “maintenance” of software should be paid to think too. Like many other pioneers of computer science, Lehman lived the computer revolution from its conception. His early work was dedicated to building some of the first computers, and by the end of his life he was witnessing the ubiquity of mobile computing. It is likely that he would have spend his life working on hardware, had it not been for the few years he spent at IBM between 1964 and 1972. IBM had originally hired him to help build physical computers; but in 1968 in a radical change of direction, he was asked to investigate programming practices within the company.2 This project took him to study the development of the operating system IBM S/360 and its successor, IBM S/370. 1He would later attend Imperial College London, where he received a PhD in 1957. 2According to Laszlo Belady, “Lehman at the time ’was on the shelf’ [...] IBM never fired anyone. Instead, they put them ’on the shelf.” [1] To put it into context today: IBM S/360 was an operating system for the IBM 360, a computer with up to 8 MBytes of memory; its fastest models could not reach speeds of 0.2 MIPS.3 Lehman discovered that programmers were becoming increasingly interested in assessing their productivity, which they measured in terms of daily SLOCs and passing unittests. He noticed that productivity was indeed increasing, but at the same time the developers appeared to be losing sight of the overall product. In his words, “the gross productivity for the project as a whole, and particularly the gross productivity as measured over the lifetime of the software product had probably gone down” [9]. It was at this time that he developed a close friendship with Laszlo Belady. Together they would challenge the prevailing models and assumptions of software maintenance processes, and champion the study of software evolution as a field in its own right. In 1972, Lehman left IBM to join Imperial College London, where he would continue his work in software engineering research.4 While he did not consider himself a programmer, his work at IBM had allowed him to study and understand programmers and their products better than most. He had witnessed first-hand the challenges of producing industrial programs for a real-world environment. He observed that the processes involved in developing and maintaining software formed a kind of feedback system, where the environment provided a signal that had profound impact upon the continued evolution of the system. Lehman’s engineering-influenced views on software systems and their development were in stark contrast to other well known computer scientists, such as Edsger Dijkstra, who had a more formal view on what a programs is. For Dijkstra, a program was a mathematical entity that should be derived, iteratively, from a formal statement what it was supposed to do. In this model, you start with a precise specification, and then implement a series of formal “step-wise” refinements, gradually making it more concrete, and ultimately executable. He preferred “formal derivation of program from spec through a series of correctness-preserving transformations” over more informal and traditional views of software development, and he championed the view that teaching programming should 3The project manager was Fred Brooks, later to become a professor and win the Turing Award. 4He was also instrumental in creating, at Imperial College, one the first programs in software engineering. emphasize creating a specification and then progressively transforming it into a program satisfies it [5].5 Lehman recognized the value of Dijkstra’s position, but at the same time felt that it was not a practical model for the problem space of industrial software or for the style of development he had observed at IBM. So he postulated that programs could be divided into two main categories: S-type programs, which are derived from a rigorous specification that is stated up-front, and can be proven correct if required; and E-type (evolutionary) programs, which are strongly affected by their environment and must be adaptable to changing needs [8]. In his view, E-type systems are those that are embedded in the real world, implicitly suggesting that S-type programs were less common — and thus less important — outside of the research world.6 II. LEHMAN’S LAWS OF EVOLUTION In Lehman’s view, “The moment you install that program, the environment changes.” Hence, a program that is expected to operate in the real world cannot be fully specified for two reasons: it is impossible to anticipate all of the complexities of the real world environment in which it will run; and, equally importantly, the program will affect the environment the moment it starts being used. As time passes the environment in which the software system is embedded will inevitably evolve, often in unexpected directions; the environment of a program — including its users — thus becomes input to a feedback loop that drives further evolution. A program might, at some point, perfectly satisfy the requirements of its users, but as its environment changes, it will have to be adapted to continue doing so. In the words of Lehman, “Evolution is an essential property of real-world software” and “As your needs change, your criteria for satisfaction changes”. Over time requirements will change, and software must evolve to continue to satisfy these new requirements. If the environment is the one that drives the evolution, programmers are the ones who evolve the program. Lehman noted that evolving a software system was not an easy task. He summarized his observations in what we today call Lehman’s Laws of Software Evolution (adapted from [10], [4]): 1) Continuing change — An E-type software system7 that is used must be continually adapted, else it becomes progressively less satisfactory. 2) Increasing complexity — As an E-type software system evolves, its complexity tends to increase unless work is done to maintain or reduce it. 5There are symmetries between their positions and those of the disciplines of engineering and mathematics; this is reinforced by the fact that Lehman viewed software as a feedback system — a typical engineering model — while Dijkstra viewed it as a mathematical concept. 6Originally Lehman created a third category: P-type. P-type programs cannot be specified and their development is iterative. Later, he decided that Ptype programs were really a subset of E-type, and he reduced his classification to E-type and S-type programs only. 7Lehman used the term program, but we decided to update the descriptions to the more current term “software system”. 3) Self-regulation — The E-type software system’s evolution process is self regulating with close to normal distribution of measures of product and process attributes. 4) Conservation of organizational stability — The average effective global activity rate on an evolving E-type software system is invariant over the product lifetime. 5) Conservation of familiarity — During the active life of an evolving E-type software system, the content of successive releases is statistically invariant. 6) Continuing growth — Functional content of an E-type software system must be continually increased to maintain user satisfaction over its lifetime. 7) Declining quality — An E-type software system will be perceived as of declining quality unless rigorously maintained and adapted to a changing operational environment. 8) Feedback System — E-type software systems constitute multi-loop, multi-level feedback systems and must be treated as such to be successfully modified or improved. While Law 8 Feedback System was the last to be formulated, arguably it should have been the first to be stated, as its themes pervade the others. As discussed above, Lehman based his observations on the notion that real world software, once deployed, forms a feedback loop. The feedback comes from many different sources, including the stakeholders (e.g., they might want new features), the environment in which the system runs (technical — e.g., new versions of the operating system might render the software system unusable unless it is adapted — and non-technical — e.g., a system for tax management might need to be updated to changes in the taxation laws), and the system itself (e.g., its own defects might need to be fixed). Thi