Laws of Software Evolution – and A Couple Other Notable Observations

The development of IBM’s OS/360 in the 1960’s was a seminal event for software engineering leading to the well known book, The Mythical Man-Month, and also The Laws of Software Evolution spearheaded by Professor Meir Lehman, University of London.  These laws are worth understanding for AS/400 shops supporting legacy RPG systems, as they give some insight into how software seems to degrade over time.  And there are hints of some possible lessons for going forward.  So here is a summary of the eight laws.  I will add notes where a given law is not reasonably self-explanatory, but put on your thinking caps, you’re going to have to think a little to absorb these.

1. Software that is used must be continually adapted else it becomes progressively less satisfactory.
   
2. As a program evolves its complexity increases unless work is done to maintain or reduce it.
   
3. The evolution process is self-regulating with close to normal distribution of measures of product and process attributes. I.e., the forces acting on software evolution in an organization are comprised of positive and negative feedback dynamics that follow the evolution of the organization over time.
4. The average effective global activity of an evolving system is invariant over the software’s lifetime. I.e., on average, maintenance work tends to neither go up nor down over the long term as changing business needs continually drive maintenance needs.
5. During the life of an evolving software product the content of successive releases is statistically invariant. This essentially refers to the volume of content change, i.e, the amount of system changes or enhancements.  The principle here is that an organization only has so much capacity to understand and adapt to software changes, and this serves as a limit on the content of releases.
6. Functional content of a program must be continually increased to maintain user satisfaction over its lifetime. The impetus for this law is the fact that the functionality delivered in a given project is always constrained by schedule or budget, and therefore there will always be pressure to increase the functionality through successive maintenance projects.
7. Software systems will be perceived as having declining quality unless rigorously maintained and adapted. There is something called The Principal of Software Uncertainty which states that even if software performs exactly to specification its performance in the real world is ultimately unpredictable due to uncertainty about the real world.  Over time that uncertainty increases and accumulates, and software is more and more likely to suffer decreasing “quality”, or value.
8. The evolution of software systems is governed by multi-loop, multi-level feedback systems and must be dealt with as such to be successfully improved. Examples of feedback loops are: 1) the use of the software by users and their demands for changes, 2) the growing complexity of the software and the ability of programmers to maintain it.  The results of both of these activities affect future iterations of themselves and each other.

So there you have the eight Laws of Software Evolution as presently generally agreed.  The impact of some of these on IT organizations is somewhat subtle, but in my own experience I can see the presence of all of them in my own past clients.

Since I’m on this topic let me add one other observation that might be considered a “law”, as described by Alain April, author of a recent authoritative book on software maintenance, “the act of maintaining software tends to degrade it.” My sense is that this is so obvious to most people’s experiences that it needs no explanation.

And I’ll throw in one more, that as far as I know this was first said by Joel Spolsky, of Joel On Software, “it is harder to read code than write it.” That is one of those observations that your experience leads you to accept as true upon hearing, but nevertheless has a certain shock value.

I think the primary overall benefit that AS/400 iSeries RPG shops can gain from these is concerned with management education.  I have personally been involved at least three very large RPG systems that I architected in the 1980’s and that are still in operation.  If my clients had comprehended these laws at the time, and foreseen that the software would be in use for over 20 years, then I believe better decisions could have been made about managing the software by taking a long term view.  This could have made these systems even more valuable for these organizations over their lifetime.