Lehman's Laws of Software Evolution

by Paul Adams

The first post in a series regarding Lehman's Laws and how they impact your engineering.

Some of my favourite "things" in the theory of engineering management are Lehman's Laws of Software Evolution. These laws are almost always sitting at the back of my mind as I work; they have implications for the product, the team and the process.

I am going talk a little about how I see these laws relating to agility and why you should maybe also think on them. But that's going to take a few posts. For now, I want to start with the nature of software evolution itself.

So... Software Evolution?

Kindly, someone over at Wikipedia has defined "software evolution" in a way that I like...

Software evolution is the term used in software engineering (specifically software maintenance) to refer to the process of developing software initially, then repeatedly updating it for various reasons.

I like this definition because it starts from the begining. With the empty file. All software development starts with the evolution (and maintenance) of an empty file. The final software product, however, does not necesarilly evolve.

Lehman broadly categorises software into one of three types:

  • S-type software is built to an exact specification. The software evolves until the product meets the specification but, by definition, no further.
  • P-type software implements a specific set of procedures. How this is any different from S-type software... your guess is as good as mine.
  • E-type software is linked into the environment in which it runs. It has to adapt to that environment to remain successful.

Broadly, I guess we reduce this to "some software evolves, some doesn't". In general, I think it is pretty easy to identify which is which. What is not so obvious: how does the type of the software affect the environment in which it is being developed?

These Blog Posts

I'm going to tackle Lehman's Laws one-at-a-time in blog posts. For each I will try to provide insight from my own experience and relate the law to agile practice.

But, for now, head on over to Wikipedia and read around Lehman's Laws and get a feel for how they relate to your experience.