Papers

• Lehman, M. and Ramil, J. F., "An Approach to a Theory of Software Evolution", in Proceedings of International Workshop on Principles of Software Evolution (IWPSE), Vienna, Austria, September 10 - 11, pp. 70-74
• Lehman, M. and Ramil, J. F., "Evolution in Software and Related Areas", in Proceedings of International Workshop on Principles of Software Evolution (IWPSE), Vienna, Austria, September 10 - 11, pp. 1-16

Lehman's Laws of SE

• Lehman et al. based the laws on observations (1974) of a few commercially developed systems.
• 3 to 8 laws
• Are these really "laws"?
• Limited data
• However, important start

Types of Systems

• S-type programs - Specified formally, no changes needed
• P-type programs - Requires iterative process to find

• E-type programs - Must evolve over time

• In general, the laws apply to E-type programs.

Law I: Continuing Change

A program that is used must be continually adapted else it becomes progressively less satisfactory

• Similar to a biological system. However, mismatches are between the software and its operational domain (environment).
• Changes in the operational domain invalidate assumptions made in the software.
• The need for continuous adaptation and evolution is intrinsic.
• The development, installation, and operation of software change both the software and the operational domain.
• A software system achieves evolution in a feedback-driven maintenance process.
• If evolution is not allowed to occur, the degree of satisfaction declines.
• Examples GPS application, security software

Law II: Increasing Complexity

As a program is evolved, its complexity increases unless work is done to maintain or reduce it

• Similar to The Second Law of Thermodynamics and the concept of entropy, software becomes more complex over time due to added features, changes, and fixes.
• Complexity raises the bar for future modifications, making them more resource-intensive.
• Parts of the system increasingly interact in unstructured ways, leading to increased entropy.
• Growth in complexity leads to more resources to make changes. Reducing complexity takes time away from making changes.
• Requires a balance of new features and reducing complexity.
• Examples social media integration effect on privacy settings, single-purpose tools grow into all-in-one solutions

Law III: Self Regulation

The program evolution process is self-regulating with close to normal distribution of measures of product and process attributes

• The project isn't isolated but is part of a broader organizational ecosystem that influences it through various metrics and feedback loops.
• Feedback (pay, allocation of resources, free lunches) from all levels of the larger organization work to keep the project in line.
• Over time, all iterations will have the same characteristics (bugs, complexity, etc.). Over time, all projects will have the same characteristics.
• This is a good thing if the organization's products have good characteristics. If not, then this is a bad thing.
• Examples Quick deployment vs. thorough testing

Law IV: Conservation of Organisational Stability

The average effective global activity rate on an evolving system is invariant over the product's lifetime

• Despite best efforts, the rate of feature release or task completion remains relatively constant over the lifespan of a product due to various constraints.
• Counter-intuitive. People (especially managers) believe that managers make decisions that affect activity.
• Managers do control what to do and the resources to do it.
• However, union rules, lack of skills in available personnel, etc., all constrain management.
• System characteristics, e.g., complexity, also constrain it.
• Providing additional resources may reduce the overall effectiveness Brooks.
• Example Regulatory requirements prevent rapid change

Law V: Conservation of Familiarity

During the active life of an evolving program, the content of successive releases is statistically invariant

• The team makes good progress when all members know the goals.
• The more changes/additions to the software, the more difficult it is for everybody to be familiar with all the goals.
• The more significant the change, the less likely everybody is familiar with it.
• There are trigger points when this occurs.
• Examples Frequent pivoting and decreased productivity, "feature creep"

Law VI: Continuing Growth

The functional content of a program must be continually increased to maintain user satisfaction over its lifetime

• This law appears the same as Law I: Continuing Change but isn't
• The team does not implement all the original requirements due to resources (budget, time, etc.).
• Eventually, users will request the unimplemented requirements.
• Examples Cloud integration, collaboration features, air-quality index

Law VII: Declining Quality

… programs will be perceived as of declining quality unless rigorously maintained and adapted to a changing operational environment

• Unless constantly updated and refined, the software may suffer in perceived quality due to the ever-changing environment and elevated user expectations.
• Software that has been performing satisfactorily for even a long time can suddenly exhibit unexpected, previously unobserved behavior.
• This law reflects the gap between software and the real-world operational environment.
• The real-world operational environment is always changing.
• This uncertainty about software increases with time unless the team takes action during maintenance.
• Familiarity breeds contempt. User satisfaction will change over time.
• Examples Email service, new file formats

Law VIII: Feedback System

Programming Processes constitute Multi-loop, Multi-level Feedback systems and must be treated as such to be successfully modified or improved

• Software development involves multiple feedback mechanisms at different levels and cycles, making it crucial to manage them comprehensively for the system to evolve successfully.
• All other parts of this set of laws include feedback.
• Multi-loop: various iterations
• Multi-level: users, development team, testing, management, critics