The paper under review is “Software Aging” by David Parnas. This 1994 paper provides a humorous look into the concept of software aging at a time when age was beginning to show its face in the software world. The paper examines the causes of software aging, its effects, and explores potential mitigating techniques. It uses wonderful tongue-in-cheek references to make its points and draws parallels between software aging and human aging, which made it an enjoyable read.
What is Software Aging?
The paper begins by explaining what software aging is. After having read this paper, my understanding of software aging is that it is the inevitable degradation of software over time. As aging is inevitable, software can either age gracefully or poorly, depending on its design with an eye towards maintainability and the very maintenance itself.
The Two Root Causes of Poor Software Aging
Parnas contends that poor software aging has two root causes.
1. Lack of Movement (Obsolescence)
The first cause is obsolescence due to the software not being modified to meet current needs. I tend to concur with this statement, as many software offerings that are designed for a previous computing era may have a dated appearance and poor performance characteristics in a more modern environment if not updated appropriately.
For instance, software designed for a previous Operating System version may use GUI elements and programming practices designed for that environment, whereas a current OS version may support a different motif and programming paradigm that are considered more favorable. A relevant example would be Windows applications that use the Winforms paradigm. Winforms was the appropriate Windows Application model for older versions of Windows; it was replaced by, among others, WPF and MVVM models in later versions. As such, non-updated applications would have a dated look and would be less performant and, thus, less-desirable than a more modern looking updated interface using faster data acquisition models. This type of obsolescence is termed as “Lack of Movement” by Parnas, and that description makes sense. Software that does not move forward falls to the wayside in favor of updated or otherwise modern software.
2. "Ignorant Surgery"
The second cause of software aging is termed as “Ignorant Surgery.” By this, Parnas means that software can age poorly if changes made to it are made by people who do not understand the original design or programming intent. This added complexity compounds the original complexity and can add defects to the code.
Personally, I have seen this come to fruition many times in the wild, and this scenario is usually what results in new products becoming the market share leader. For instance, Internet Explorer used to be a very slick browser that had decent performance characteristics. Over time, as new versions came out, the software became extremely bloated and buggy, and market share decreased as a result. The new leader was Google Chrome, which was lightweight and quite performant. However, as it has aged, it too has become slow, bloated, and buggy much like Internet Explorer. I believe this to be because the software has become far more complex as it has been modified during the aging process; all of the lightweight original design has been tossed aside in favor of increased complexity.
The Costs of Software Aging
The costs of software aging are discussed.
- The Cost of Updating: Updating software to include new features and handle new environments is a complicated endeavor. For starters, it could be that the software needs to operate using a new paradigm altogether; for example, the Winforms to WPF transition I brought up earlier. In that case, the original software would merely be a kernel that the WPF wrapper would be built around, and this would be a significant undertaking. The change would be so complex that defects would assuredly be introduced, and the updated software would not likely perform well, resulting in increased costs due to the need to fix the defects and customer defections.
- Reduced Performance: Software bloat caused by age simply results in poor performance characteristics. This diminished performance either requires upgraded hardware or will result in further customer defections, as younger software may not exhibit this bloat (e.g., the Google Chrome example from above). Furthermore, the bloated software will be more complex due to the modifications present resulting in more defects. Defects will be introduced due to this complexity, and more defects will be introduced during bug “fixes.” As such, the software can be rendered obsolete, as the cost to maintain it will be prohibitive.
Mitigating Techniques: Aging Gracefully
All is not lost, however. Aging is inevitable, as stated before, and there are things that can be done to mitigate this in order for the software to age gracefully.
- Change-Driven Design: The concept presented to mitigate poor aging is to design with aging in mind. The idea presented in this paper, change-driven design, is not a revolutionary concept, so I feel that this paper is intended for students rather than academia. Basically, Parnas advocates using sound design principles from the get-go. He goes even further and states that the object-oriented paradigm provides the tools necessary to control poor software aging. This is a true statement, in that OOP allows for the modification of various pieces of a software project via abstraction. In other words, modules can be changed and dropped into the existing software without much effect on the code at large. These modules can be black boxes, as it is, with inputs and outputs to be utilized by the software. I feel this is technically correct, but OO is only good if the model is not violated for expedience. Also, this idea does not guard against complete paradigm shifts; however, as stated before, the original software can exist as a kernel, and the new paradigm employed as a wrapper of sorts. Even if aging is truly inevitable, it most certainly does not have to occur poorly.
- Documentation: Naturally, quality documentation does help to spell out programmer intent to a new crop of programmers on a project. If the intent is known, then the design can be respected and re-employed, rather than counteracted by a poor design in other parts of the code.
- Proper Code Reviews: It is presented that code changes should be reviewed in order to be certain that the design is respected and that the code will not contribute to the degradation of the product. I believe this to be a decent assertion; however, in practice, reviews, if not performed by independent groups, tend to become a circle of groupthinkers who do not wish to make waves amongst their coworkers for fear that their code will receive increased scrutiny when it comes time for their own code to be reviewed. However, if this were to happen appropriately, then I do suppose that this could help to ensure that changes respected the original design and intent.
Mitigating Advanced Software Decay
Parnas presents a few methods in which to mitigate software that has already begun a slide into poor aging. These methods include stopping the deterioration via using proper design principles for changes (in other words, not contributing to the deterioration any further), retroactive documentation, amputation, and restructuring.
I feel that these are fine ideas, in that respecting the current design and utilizing proper design principles (OO) for changes does help to mitigate the aging process. However, what typically does occur are the latter two: amputation and restructuring. It has been my experience that aged software usually loses its obsolete features and old sections are rewritten. Once this occurs, it is a safe bet that the software is on its way into obsolescence and retirement. This is because both of those options are costly, and either a new version should be written from scratch, or the company should find a different package with which to make money, as the market share is probably lost for good.
Conclusion
After decades, the concepts presented in this paper have held up rather well. Software can age poorly if the design is not well-understood and if changes do not respect the design. Using Object-Oriented principles does help to ensure that changes can be implemented in a standardized manner that respects well-established design principles. However, this is not the silver bullet. There are many mitigating techniques that can be employed, and the advent of modern change control systems has proved to be quite helpful in ensuring that changes are implemented properly and methodically.
Written by Dan Shaeffer. Systems architecture notes and technical essays can be found at danielshaeffer.com.
