Lehman's laws of software evolution

Last updated November 15, 2024

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

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

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

^{[ original research? ]}

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.

Related Research Articles

<span class="mw-page-title-main">Software testing</span> Checking software against a standard

Software testing is the act of checking whether software satisfies expectations.

Software development is the process of designing and implementing a software solution to satisfy a user. The process is more encompassing than programming, writing code, in that it includes conceiving the goal, evaluating feasibility, analyzing requirements, design, testing and release. The process is part of software engineering which also includes organizational management, project management, configuration management and other aspects.

In the context of software engineering, software quality refers to two related but distinct notions:

Iterative design is a design methodology based on a cyclic process of prototyping, testing, analyzing, and refining a product or process. Based on the results of testing the most recent iteration of a design, changes and refinements are made. This process is intended to ultimately improve the quality and functionality of a design. In iterative design, interaction with the designed system is used as a form of research for informing and evolving a project, as successive versions, or iterations of a design are implemented.

Continuous integration (CI) is the practice of integrating source code changes frequently and ensuring that the integrated codebase is in a workable state.

Software evolution is the continual development of a piece of software after its initial release to address changing stakeholder and/or market requirements. Software evolution is important because organizations invest large amounts of money in their software and are completely dependent on this software. Software evolution helps software adapt to changing businesses requirements, fix defects, and integrate with other changing systems in a software system environment.

Azure DevOps Server, formerly known as Team Foundation Server (TFS) and Visual Studio Team System (VSTS), is a Microsoft product that provides version control, reporting, requirements management, project management, automated builds, testing and release management capabilities. It covers the entire application lifecycle and enables DevOps capabilities. Azure DevOps can be used as a back-end to numerous integrated development environments (IDEs) but is tailored for Microsoft Visual Studio and Eclipse on all platforms.

In software development and other information technology fields, technical debt is the implied cost of future reworking because a solution prioritizes expedience over long-term design.

Meir "Manny" Lehman, FREng was a professor in the School of Computing Science at Middlesex University. From 1972 to 2002 he was a Professor and Head of the Computing Department at Imperial College London. His research contributions include the early realisation of the software evolution phenomenon and the eponymous Lehman's laws of software evolution.

Business agility refers to rapid, continuous, and systematic evolutionary adaptation and entrepreneurial innovation directed at gaining and maintaining competitive advantage. Business agility can be sustained by maintaining and adapting the goods and services offered to meet with customer demands, adjusting to the marketplace changes in a business environment, and taking advantage of available human resources.

API testing is a type of software testing that involves testing application programming interfaces (APIs) directly and as part of integration testing to determine if they meet expectations for functionality, reliability, performance, and security. Since APIs lack a GUI, API testing is performed at the message layer. API testing is now considered critical for automating testing because APIs serve as the primary interface to application logic and because GUI tests are difficult to maintain with the short release cycles and frequent changes commonly used with Agile software development and DevOps.

In software engineering, a software development process or software development life cycle (SDLC) is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

DevOps is a methodology in the software development and IT industry. Used as a set of practices and tools, DevOps integrates and automates the work of software development (Dev) and IT operations (Ops) as a means for improving and shortening the systems development life cycle. DevOps is complementary to agile software development; several DevOps aspects came from the agile way of working.

Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate. Continuous testing was originally proposed as a way of reducing waiting time for feedback to developers by introducing development environment-triggered tests as well as more traditional developer/tester-triggered tests.

Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.

Parasoft C/C++test is an integrated set of tools for testing C and C++ source code that software developers use to analyze, test, find defects, and measure the quality and security of their applications. It supports software development practices that are part of development testing, including static code analysis, dynamic code analysis, unit test case generation and execution, code coverage analysis, regression testing, runtime error detection, requirements traceability, and code review. It's a commercial tool that supports operation on Linux, Windows, and Solaris platforms as well as support for on-target embedded testing and cross compilers.

In software engineering, a microservice architecture is an architectural pattern that arranges an application as a collection of loosely coupled, fine-grained services, communicating through lightweight protocols. A microservice-based architecture enables teams to develop and deploy their services independently, reduce code interdependency and increase readability and modularity within a codebase. This is achieved by reducing several dependencies in the codebase, allowing developers to evolve their services with limited restrictions, and reducing additional complexity. Consequently, organizations can develop software with rapid growth and scalability, as well as implement off-the-shelf services more easily. These benefits come with the cost of needing to maintain a decoupled structure within the codebase, which means its initial implementation is more complex than that of a monolithic codebase. Interfaces need to be designed carefully and treated as APIs.

<span class="mw-page-title-main">DevOps toolchain</span> DevOps toolchain release package.

A DevOps toolchain is a set or combination of tools that aid in the delivery, development, and management of software applications throughout the systems development life cycle, as coordinated by an organisation that uses DevOps practices.

TestOps refers to the discipline of managing the operational aspects of testing within the software delivery lifecycle.

Mobile DevOps is a set of practices that applies the principles of DevOps specifically to the development of mobile applications. Traditional DevOps focuses on streamlining the software development process in general, but mobile development has its own unique challenges that require a tailored approach. Mobile DevOps is not simply as a branch of DevOps specific to mobile app development, instead an extension and reinterpretation of the DevOps philosophy due to very specific requirements of the mobile world.

References

1 2 3 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.
1 2 3 4 5 6 7 8 9 10 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.

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.

[laws1-1] 1 2 3 Lehman, Meir M. (1980). "Programs, Life Cycles, and Laws of Software Evolution". Proc. IEEE. 68 (9): 1060–1076. doi:10.1109/proc.1980.11805.

[softwarelaws-2] 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.

[HerraizRodriguez2013-3] 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.

[laws1-5-4] 1 2 3 4 5 6 7 8 9 10 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.

[5] 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.

[1]

[2]

[3]

[4]

[5]