Lehman's laws of software evolution

Observing that most software is subject to change in the course of its existence, the authors set out to determine laws that these changes will typically obey, or must obey for the software to survive.[1]

In his 1980 article,[1] Lehman qualified the application of such laws by distinguishing between three categories of software:

• An S-program is written according to an exact specification of what that program can do. For example, a program to find solutions to the eight queens puzzle would be an S-program. These programs are mostly static and shouldn't evolve much.
• A P-program is written to implement certain procedures that completely determine what the program can do (the example mentioned is a program to play chess)
• An E-program is written to perform some real-world activity; how it should behave is strongly linked to the environment in which it runs, and such a program needs to adapt to varying requirements and circumstances in that environment

The laws are said to apply only to the last category of systems.

All told, eight laws were formulated:

1. (1974) "Continuing Change" — an E-type system must be continually adapted or it becomes progressively less satisfactory.[4]
2. (1974) "Increasing Complexity" — as an E-type system evolves, its complexity increases unless work is done to maintain or reduce it.[4]
3. (1974) "Self Regulation" — E-type system evolution processes are self-regulating with the distribution of product and process measures close to normal.[4]
4. (1978) "Conservation of Organisational Stability (invariant work rate)" — the average effective global activity rate in an evolving E-type system is invariant over the product's lifetime.[4]
5. (1978) "Conservation of Familiarity" — as an E-type system evolves, all associated with it, developers, sales personnel and users, for example, must maintain mastery of its content and behaviour to achieve satisfactory evolution. Excessive growth diminishes that mastery. Hence the average incremental growth remains invariant as the system evolves.[4]
6. (1991) "Continuing Growth" — the functional content of an E-type system must be continually increased to maintain user satisfaction over its lifetime.
7. (1996) "Declining Quality" — the quality of an E-type system will appear to be declining unless it is rigorously maintained and adapted to operational environment changes.[5]
8. (1996) "Feedback System" (first stated 1974, formalised as law 1996) — E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base.

In the dynamic world of modern software engineering, the Laws of Software Evolution continue to hold a profound relevance. These laws, originally formulated by Lehman and Belady in the 1970s, provide enduring insights into the nature of software systems and their evolution. In today's software development landscape, where agility and adaptability are paramount, these laws serve as guiding principles.

"Continuing Change" is a foundational concept, emphasizing that software must evolve continually to remain satisfactory[4]. This aligns perfectly with agile development methodologies, where iterative updates and feature enhancements are the norm.

"Increasing Complexity" is another key law that underscores the need for active management of complexity, particularly in large and long-lived software projects[4]. As software systems grow, modern engineering practices such as modular design, microservices, and DevOps help control and reduce complexity, ensuring that software remains maintainable and scalable.

The Laws of Software Evolution also find relevance in the context of DevOps and continuous integration/continuous deployment (CI/CD). In a DevOps-driven environment, the "Continuing Growth" law[4] is exemplified as software features must be continually expanded to meet evolving user demands and maintain user satisfaction.

The "Declining Quality" law is a stark reminder that software quality can deteriorate over time without rigorous maintenance[4], highlighting the importance of automated testing and quality assurance in modern software development. Furthermore, the "Feedback System" law [4] reinforces the idea that software evolution is a feedback-driven process, with multiple loops and agents involved.

This resonates with the emphasis on collaboration and feedback within DevOps practices, ensuring that software is developed, tested, and deployed with a focus on continuous improvement. In summary, the Laws of Software Evolution continue to guide software engineers in navigating the complexities of modern development, from agile methodologies to DevOps, helping them deliver robust, evolving software systems.