In the software industry, we have a tendency to reinvent the same concept and give it a new name. We do this over and over again.
Some of these reinventions are hotly debated, as is the case with the recent controversy surrounding Micro Services and whether or not is a re-branding of Services Oriented Architecture (SOA).
Other concepts are a rediscovery of ideas so old that many might not realize that these ideas were originally described decades ago.
One recent example of this is that I have noticed people describing a concept that was originally described as Software Aging by David Parnas in 1994.
Who is David Parnas?
There’s a good chance that you may not have heard of David Parnas, but he is a very influential researcher in the field of software engineering.
Parnas originally proposed concepts such as modularization and information hiding/encapsulation. Today, we rely on encapsulation in our software design every day. Surprisingly, in the early 1970’s these ideas were considered very controversial. In fact, the famous book Mythical Man Month by Fredrik P. Brooks had a chapter devoted to arguing against Parnas’ ideas. In the 20 year anniversary of Mythical Man Month, Brooks included a new article titled “Parnas was right and I was wrong about Information Hiding”.
If you are interested in reading some of David Parnas’s most influential articles, you can find them here:
On the criteria to be used in decomposing systems into modules (1972)
On the design and development of program families (1976)
Software Aging (1994)
What is Software Aging?
To quote the abstract of the original article:
Programs, like people, get old. We can‘t prevent aging, but we can understand its causes, take steps to limits its effects, temporarily reverse some of the damage it has caused, and prepare for the day when the software is no longer viable. A sign that the Software Engineering profession has matured will be that we lose our preoccupation with the first release
and focus on the long term health of our products.
As I mentioned earlier, the concept that software ages or deteriorates over time is something that I hear people try to describe from time to time using various analogies. Most recently, I saw this tweet from Jessica Kerr:
Jessica’s analogy is good, and for me it served as a reminder to re-read the original Software Aging article as well as the abbreviated PowerPoint slides.
Parnas describes 2 types of aging:
The first is caused by the failure of the product’s owners to modify it to meet changing needs; the second is the result of the changes that are made.
He goes on to describe in great detail the reasons why this happens, the costs associated with software aging, and what we can do to minimize those costs.
One of the big take-away for me is that when designing a system, we need to think past the first release to when the software is old.
Overall, it is a great read and something I would recommend to anyone who is building software for a living.