I have a hard time understanding #3 and #8 of Lehman's Laws of Software Evolution.

The laws are:

  1. (1974) "Self Regulation" — E-type system evolution processes are self-regulating with the distribution of product and process measures close to normal


  1. (1996) "Feedback System" (first stated 1974, formalised as law 1996) — E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base

The rest of the laws are clear to me.

Could someone explain these two laws?

  • 3
    What's unclear?
    – neontapir
    Apr 22, 2015 at 15:59
  • Most of it. I guess it's the language in combination with not having clear context for them. If someone could provide an example where the law(s) clearly apply, I think that would help greatly.
    – Willy G
    Apr 22, 2015 at 16:20

4 Answers 4


After talking to a professor at my university, and using the information provided by Ilyas and Boris (I will +rep as soon as I recieve 15 rep myself), this is what I have concluded:

Law 3 specifies that the growth of the system will follow the normal distribution curve. This means that the growth will be slower in the beginning and end of the life cycle compared to in the middle.

Law 8 states that software evolution is a complex process where feedback shall be collected from multiple sources (users, managers, runtime environment, application domain, etc.) to achieve significant improvement during the evolution process.

The following link is a pdf which contains alternate explanations for each of the eight laws: http://www.engr.uvic.ca/~seng371/lectures/L12-371-S13-bw.pdf



  1. (1974) "Self Regulation" — E-type system evolution processes are self-regulating with the distribution of product and process measures close to normal

In other words 'an E-type systems growth inevitably slows as it grows older'.



  • Additional information. 'Distribution is close to normal' refers to a normally distributed data set (statistics). Apr 25, 2015 at 0:04

Not sure about law 3 yet, but here's my take on law 8:

Law 8 would be a perfect example of a successful agile project. The system is adapted to the changing requirements of users, product owners and other stakeholders. By using the system, users find out what they really want to do with the system. Product owners and management prioritize new features according to a changing environment and the team discovers better ways of doing things by gaining domain knowledge and experience. That sounds a lot like a multi-level, multi-loop, multi-agent feedback system.

  • 1
    Nice answer, but I don't think that agile project is entirely appropriate, because a the term project is used to describe something that has a defined goal. Lehman's laws take over once the system has been created and deployed. The modern buzz-word that I think most closely describes this law is DevOps.
    – Jay Elston
    Apr 23, 2015 at 1:27
  • @JayElston Agile projects take input from the stakeholders after the initial build in order to drive the direction and possibly change the goals. They don't necessarily have a single defined goal or timeline for the entire duration of the project/product. It seems to me like it fits
    – Izkata
    Apr 25, 2015 at 3:21
  • 1
    Granted that the goals of an Agile project can change as the project moves along, but a project has some definite goal in mind (in the eyes of the stakeholders). One those goals are met, and a system has been created, it will still evolve. If it is a useful system, its lifetime can be measured in years, and over the years different stakeholders may sponsor additional projects to add more features, and also some team will be tasked with the ongoing ownership of the projects (bug fixes, technology roadmapping, etc. It is this evolution that Lehman's laws is covering, not the initial project.
    – Jay Elston
    Apr 27, 2015 at 1:10

Agile is a good way to understand the 8th Law, as well as the 1st and 2nd law, because  Agile techniques work because they embrace Lehman's laws. Agile gives practical tools that make the realities described by the Lehmans laws in general, and the 8th in particular, manageable, and stable.   The insight behind the 8th law is that the process of software development is composed of three key - but very different ingredients - people, organizations of people, and software.

  1. People define what the software should do and how it will be used. People develop software that realizes those requirements. People are subjective, imperfect, irrational, and biased (except me of course !). Organizations of people amplify this by introducing more stakeholders, with differing interests, opinions, and politics. Think of all of this as a complex feedback loop - not in the sense of say, an airplane control system - but like the world economy or even a government trying to manage a pandemic.

  2. Software - unlike people - is "perfect" - unbiased, deterministic, it does exactly what it's programmed to do. Software has no notion of "tolerance" - there is no relationship between the nature of the error/fault and the size and criticality of the outcome. Also, changing software is conceived as "easy" - just type a few magic words, and the problem if fixed, redeployment is fast and automatic. So software changes behave like positive feedback - changes are very easy, but the smallest input can cause an unproportionate large output. 

The combination of human users of the system, a large human organization manipulating an easy to change and deliver software base, leads to a constant desire and pressure for change.  The fact that today's systems have multiple users, many features and there are many many stakeholders means that the entire system has a life of its own - not completely under the control of any particular person or organization.

Agile recognizes that systems evolve (the 1st law), hence it encourages, iterative, incremental, and evolutionary growth. Agile encourages small, self-managing teams, i.e. it aims to simplify the 8th law feedback loops. It encourages measuring/analyzing/changing the development process itself - yet another 8th law feedback loop. Agile also recognizes the inevitability of technical debt and the need for refactoring (yet another loop) - accepting and embracing the 2nd law.

The 3rd law basically says that observations of the rate of real, large software systems, shows that this growth is not totally under the control of the managers - the people, the organization, and the nature of software combine in a way that makes the development process behave in a statistically predictable - cycles of increased and decreased development progress (negative feedback loop), increasing growth (the 1st law), and eventual decay (because of unmanaged entropy - the 2nd law).    

Not the answer you're looking for? Browse other questions tagged or ask your own question.