Ancient lore: Lehman's laws of software evolution

ancient lore  

While we might like to think of software development as a young field, it’s actually been around for a long time. Many of the fundamental ideas (that are sadly often neglected) have been around for decades. These include the Mythical Man Month from 1975, modularity as described by On the criteria to be used in decomposing systems into modules from 1972, the concepts of coupling and cohesion as described by Structured Design from 1979 and Conways law from 1967.

I recently came across another important body of work: Lehman’s laws of software evolution These laws, which were first published in 1974, describe the forces (a.k.a concerns) that influence evolution of an application. Some laws drive the evolution of an application while others impede it. Let’s first look at the kind of applications that Lehman’s laws apply to. After that I’ll describe the laws themselves.

The scope of Lehman’s laws

Lehman described three different types of applications:

  • S-type (specified) programs are derivable from a static specification and can be formally proven as correct or not.
  • P-type (problem-solving) programs attempt to solve problems that can be formulated formally, but which are not computationally affordable. Therefore, the program must be based on heuristics or approximations to the theoretical problem.
  • E-type (evolutionary) programs are reflections of human processes or of a part of the real world. These kinds of programs try to solve an activity that somehow involves people or the real world.

Lehman’s laws apply to E-programs. What makes the laws especially relevant is that modern enterprise applications appear to be E-programs. And, since the world changes, E-type programs must change as well. Let’s now look at the laws themselves.

Lehman’s eight laws of software evolution

Lehman’s laws have evolved over the years. They have grown from the original 3 laws to 8 laws. Here they are as described by the 2013 paper The Evolution of the Laws of Software Evolution

Some laws intutively feel correct

Many of these laws feel correct especially I (continuing change), II (increasing complexity), VI (continuing growth), and VII (declining quality). Applications continue to grow as more and more features are added to satisfy the needs of the users. And development slows down as the system becomes more complex and its quality degrades unless architects are actually allowed to do architecture.

Others explain why software development slows down

Moreover, perhaps the other laws - III (Law of Self Regulation), IV (Law of Conservation of Organizational Stability), V (Law of Conservation of Familiarity) and VIII (Law of Feedback System) - also explain why development slows down as the systems get large. After all software is developed by and for humans who have limited cognitive capacity. Developers can only keep so much of the system in their heads at once. Users struggle to understand the system and its features. And organization’s certainly struggle to change their structure and ways of working.

Real world observations

Lehman originally formulated his laws based on a study of the OS/360 operating system, whch was first released in 1966. But The Evolution of the Laws of Software Evolution paper describes how recent investigations of open-source have have mixed results. For example:

More recently, Israeli and Feitelson [2010] also studied the Linux kernel, trying to find out whether it fulfilled the laws or not. They found that the superlinear growth pattern that had been found in 2000 by Godfrey and Tu, and confirmed in 2005 by Robles et al., stopped with release 2.5 of Linux. From that release on, growth has been linear.

Other studies have validated some laws and invalidated others:

If we examine Table V, it seems clear that Laws I (continuous change) and VI (continuing growth) have been validated by all the studies. Laws II (increasing complexity), IV (conservation of organizational stability), and V (conservation of familiarity) have been invalidated for most of the cases. These three laws are related to the growth pattern of the project. Software projects whose growth accelerates over time do not fulfill these three laws.

Perhaps open-source is different than enterprise development

Perhaps the reason some laws don’t apply to open-source is that it’s inherently very different (distributed, decentralized, cross-functional, loosely coupled, agile, comitter longevity, …) than development within many enterprises (centralized, hierarchical, siloed, overly complex, agilefall, higher staff turnover, … ).

What do you think?

I find Lehman’s laws fascinating. What do you think? Do they describe the evolution of your application?

Need help improving software delivery?

I’m available to help your organization. I provide consulting and workshops.


ancient lore  


Copyright © 2024 Chris Richardson • All rights reserved • Supported by Kong.

About Microservices.io

Microservices.io is brought to you by Chris Richardson. Experienced software architect, author of POJOs in Action, the creator of the original CloudFoundry.com, and the author of Microservices patterns.

Upcoming public workshops: Microservices and architecting for fast flow

In-person: Berlin and Milan

DevOps and Team topologies are vital for delivering the fast flow of changes that modern businesses need.

But they are insufficient. You also need an application architecture that supports fast, sustainable flow.

Learn more and register for one of my upcoming public workshops in November.

NEED HELP?

I help organizations improve agility and competitiveness through better software architecture.

Learn more about my consulting engagements, and training workshops.

LEARN about microservices

Chris offers numerous other resources for learning the microservice architecture.

Get the book: Microservices Patterns

Read Chris Richardson's book:

Example microservices applications

Want to see an example? Check out Chris Richardson's example applications. See code

Virtual bootcamp: Distributed data patterns in a microservice architecture

My virtual bootcamp, distributed data patterns in a microservice architecture, is now open for enrollment!

It covers the key distributed data management patterns including Saga, API Composition, and CQRS.

It consists of video lectures, code labs, and a weekly ask-me-anything video conference repeated in multiple timezones.

The regular price is $395/person but use coupon CCMHVSFB to sign up for $95 (valid until November 8th, 2024). There are deeper discounts for buying multiple seats.

Learn more

Learn how to create a service template and microservice chassis

Take a look at my Manning LiveProject that teaches you how to develop a service template and microservice chassis.

Signup for the newsletter


BUILD microservices

Ready to start using the microservice architecture?

Consulting services

Engage Chris to create a microservices adoption roadmap and help you define your microservice architecture,


The Eventuate platform

Use the Eventuate.io platform to tackle distributed data management challenges in your microservices architecture.

Eventuate is Chris's latest startup. It makes it easy to use the Saga pattern to manage transactions and the CQRS pattern to implement queries.


Join the microservices google group