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.