In the paper Programs, Life Cycles, and Laws of Software Evolution (1980), Lehman distinguishes between three different types of software.^[1] Suffice to say that the laws of software evolution only apply to applications that solve real-world problems (E-type systems). That means they execute activities that can also be performed by a human, such as maximizing profit.

Software has to change throughout its lifecycle to continue being useful

I. Continuing Change
E-type systems must be continually adapted else they become progressively less satisfactory.

VI. Continuing Growth
The functional content of E-type systems must be continually increased to maintain user satisfaction over their lifetime.

— Lehman et al. (1997), Metrics and Laws of Software Evolution - The Nineties View

It may be a bit unorthodox to start with the first and the sixth law, but they establish an important premise: Software changes. It does so all the time. The agile movement has achieved that this fact is widely recognized in the development stage of software. But even after a software is considered feature complete adaptions of the existing system are necessary, in order to retain user satisfaction. Responses to unknown events, or adaptions to surrounding software systems all induce changes.

Another important aspect of these two laws is that the software maintenance process is not much different from the software development process. In both cases the team needs to deliver new features for the users and to adapt to changes from the outside. However, these changes come with a cost:

Changes introduce unnecessary complexity

II. Increasing Complexity
As an E-type system evolves its complexity increases unless work is done to maintain or reduce it.

— Lehman et al. (1997), Metrics and Laws of Software Evolution - The Nineties View

Since changes to software is required all the time, the software systems become increasingly complex. They deteriorate over time, unless the process is counteracted. Just like our teeth need brushing and flossing to prevent them from rotting,^[2] software systems require continuous refactoring to tackle complexity and prevent software rot. Otherwise, they will suffer from…

Failure to reduce complexity and adapt to changes lets a system deteriorate

VII. Declining Quality
The quality of E-type systems will appear to be declining unless they are rigorously maintained and adapted to operational environment changes.

— Lehman et al. (1997), Metrics and Laws of Software Evolution - The Nineties View

Failing to establish a software development regimen that includes merciless refactoring^[3] ultimately leads to a steady decrease of software quality. Accrued software dept will reduce the quality of the system to a point where it is cheaper to rewrite the software from scratch than to fix the existing system.

The previous sections paint a dark picture. It seemed like each and every software system is doomed to fail. This is absolutely not true. Keep in mind that the laws are meant to guide an informed decision. For example, if a software is not supposed to run for a long time, it may be more cost effective to let it deteriorate. Nevertheless, there are too many software systems in danger, because these decisions have been made unconsciously. Lehman's research is decades old, yet we are still struggling today to make the right choices. It almost seems like people are inherently bad at software.

---

1. S-programs are formally defined and have a very specific scope, such as finding the greatest common denominator of two integers. P-programs solve more complex problems that are an abstraction of the real world, such as the Travelling Salesman Problem (TSP). The key differentiator to S-programs is that the usefulness of P-programs is in relation to the context in which they are applied. For example, a P-program can find the optimal solution to TSP, but it may not be applicable, because the input is too large. The third type are E-programs which recreate an activity that could be performed by a human. ↩︎

2. I believe this analogy was first established by Murphy-Hill and Black (2007) in their paper Why Don’t People Use Refactoring Tools?. They distinguished between floss refactoring, which is done in an agile fashion alongside regular development, and root canal refactoring, which is done during a dedicated period set aside for refactoring. As someone who had to learn the importance of teeth hygiene the hard way I like this analogy a lot. ↩︎

3. A term coined in Chris Sterling's (2011) book on Managing Software Dept. Unlike Sterling's original meaning, I prefer to think that merciless represents the fact that teams shouldn't get attached to existing solutions and code too much. ↩︎