Software is alive. And here’s the invariant properties found in software evolution.

Understanding these forces which drive new developments and which demising productivity will guide effective software project management.

A software product which consists of a software program may take 1 of the following classifications.

  1. Static programs (S-type)
    are derivable from a static specification, and can be formally proven correct or not. For example, a program that calculated the value of 5 x 3, where the solution is verified by the answer equalling 15.
  2. Practical programs (P-type)
    attempt to solve problems that can be formally formulated, but that are not affordable from a computational point of view. Therefore the program must be based on heuristics or approximations to the theoretical problem. For example, a simple calculator that approximates. Despite the fact that the problem to be solved can be precisely defined, the acceptability of a solution is determined by the environment in which it is embedded.
  3. Embedded programs (E-type)
    are reflections of human processes or of a part of the real world. These attempt to solve an activity that somehow involves people and the real world. They are inherently even more prone to change than P-type programs. For example, the formulation of the specification must involve opinion and judgement or the world that’s being modeled may itself change, independently from the program.

Proposed 8 Laws of Evolving Software

The invariant properties of software evolution have been scientifically examined to form a series of laws ever since 1974. These laws themselves have evolved to match changing industries and creation of new project types. No set of universal laws have been proved across all software projects, though these have been supported sufficiently across a range of software projects. The eight laws are:

  1. Law of Continuing Change
    An E-type system must be continually adapted, else it becomes progressively less satisfactory in use
  2. Law of Increasing Complexity
    As an E-type is changed its complexity increases and becomes more difficult to evolve unless work is done to maintain or reduce the complexity.
  3. Law of Self Regulation
    Global E-type system evolution is feedback regulated.
  4. Law of Conservation of Organisational Stability
    The work rate of an organisation evolving an E-type software system trends to be constant over the operational lifetime of that system or phases of that lifetime.
  5. Law of Conservation of Familiarity
    In general, the incremental growth (growth rate trend) of E-type systems is constrained by the need to maintain familiarity.
  6. Law of Continuing Growth
    The functional capability of E-type systems must be continually enhanced to maintain user satisfaction over system lifetime.
  7. Law of Declining Quality
    Unless rigorously adapted and evolved to take into account changes in the operational environment, the quality of an E-type system will appear to be declining.
  8. Law of Feedback System
    E-type evolution processes are multi-level, multi-loop, multi-agent feedback systems.

Most notably, the laws of Continuing Change, Increasing Complexity, Self Regulation, and Continuing Growth are still applicable to the evolution of today’s open source products. Understanding these laws will guide effective software project management.


  1. Towards a Better Understanding of Software Evolution: An Empirical Study on Open Source Software.
  2. The Evolution of the Laws of Software Evolution: A Discussion Based on a Systematic Literature Review.

By Scott Pineapple

software engineer & photographer
Scott is a passionate Lead Software Engineer based in Sydney NSW, transforming industries using innovative, collaborative, and lean software engineering practices.

Leave a Reply

Your email address will not be published. Required fields are marked *