ancient lore  

Ancient lore: Lehman’s laws of software evolution

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 is brought to you by Chris Richardson. Experienced software architect, author of POJOs in Action, the creator of the original, and the author of Microservices patterns.

Chris helps organizations improve agility and competitiveness through better software architecture. Learn more about his consulting engagements, and training workshops.

Upcoming public talks/workshops


Premium content and office hours is now available for paid subscribers at


Chris teaches comprehensive workshops for architects and developers that will enable your organization use microservices effectively.

Avoid the pitfalls of adopting microservices and learn essential topics, such as service decomposition and design and how to refactor a monolith to microservices.

Learn more

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

Remote consulting session

Got a specific microservice architecture-related question? For example:

  • Wondering whether your organization should adopt microservices?
  • Want to know how to migrate your monolith to microservices?
  • Facing a tricky microservice architecture design problem?

Consider signing up for a two hour, highly focussed, consulting session.

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 ILFJODYS to sign up for $95 (valid until March 12, 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 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.

ASSESS your architecture

Assess your application's microservice architecture and identify what needs to be improved.

Consulting services

Engage Chris to conduct an architectural assessment.

Join the microservices google group


Note: tagging is work-in-process

GitOps   ·  Microservices adoption   ·  ancient lore   ·  anti-patterns   ·  application api   ·  application architecture   ·  architecting   ·  architecture   ·  architecture documentation   ·  assemblage   ·  beer   ·  books   ·  containers   ·  dark energy and dark matter   ·  deployment   ·  deployment pipeline   ·  design-time coupling   ·  developer experience   ·  development   ·  devops   ·  docker   ·  eventuate platform   ·  generative AI   ·  glossary   ·  health   ·  hexagonal architecture   ·  implementing commands   ·  implementing queries   ·  inter-service communication   ·  kubernetes   ·  loose coupling   ·  microservice architecture   ·  microservice chassis   ·  microservices adoption   ·  microservicesio updates   ·  modular monolith   ·  multi-architecture docker images   ·  observability   ·  pattern   ·  refactoring to microservices   ·  resilience   ·  sagas   ·  security   ·  service api   ·  service architecture   ·  service blueprint   ·  service collaboration   ·  service design   ·  service discovery   ·  service granularity   ·  service template   ·  software delivery metrics   ·  success triangle   ·  tacos   ·  team topologies   ·  testing   ·  transaction management   ·  transactional messaging

All content


24 Jul 2017 » Revised data patterns