Lehman's laws of software evolution
In software engineering, the laws of software evolution refer to a series of laws that Lehman and Belady formulated starting in 1974 with respect to software evolution.[1][2] The laws describe a balance between forces driving new developments on one hand, and forces that slow down progress on the other hand. Over the past decades the laws have been revised and extended several times.[3]
Context
[edit]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.
The laws
[edit]All told, eight laws were formulated:
- (1974) "Continuing Change" — an E-type system must be continually adapted or it becomes progressively less satisfactory.[4]
- (1974) "Increasing Complexity" — as an E-type system evolves, its complexity increases unless work is done to maintain or reduce it.[4]
- (1974) "Self Regulation" — E-type system evolution processes are self-regulating with the distribution of product and process measures close to normal.[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]
- (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]
- (1991) "Continuing Growth" — the functional content of an E-type system must be continually increased to maintain user satisfaction over its lifetime.
- (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]
- (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.
Relevance of the Laws of Software Evolution in Modern Software Engineering
[edit]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.
References
[edit]- ^ a b c Lehman, Meir M. (1980). "Programs, Life Cycles, and Laws of Software Evolution". Proc. IEEE. 68 (9): 1060–1076. doi:10.1109/proc.1980.11805.
- ^ Lehman, M. M.; J. F. Ramil; P. D. Wernick; D. E. Perry; W. M. Turski (1997). "Metrics and laws of software evolution—the nineties view" (PDF). Proc. 4th International Software Metrics Symposium (METRICS '97). pp. 20–32. doi:10.1109/METRIC.1997.637156.
- ^ Herraiz, Israel; Rodriguez, Daniel; Robles, Gregorio; Gonzalez-Barahona, Jesus M. (2013). "The evolution of the laws of software evolution". ACM Computing Surveys. 46 (2): 1–28. doi:10.1145/2543581.2543595. ISSN 0360-0300.
- ^ a b c d e f g h i j Lehman, M. M. (1980). "On Understanding Laws, Evolution, and Conservation in the Large-Program Life Cycle". Journal of Systems and Software. 1: 213–221. doi:10.1016/0164-1212(79)90022-0.
- ^ Liguo Yu and Alok Mishra (2013) An Empirical Study of Lehman’s Law on Software Quality Evolution in International Journal of Software and Informatics, 11/2013; 7(3):469-481.