Lehman's Laws

Michael L. Collard, Ph.D.

Department of Computer Science, The University of Akron


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