We like to ignore the fact that all systems that last long enough become “legacy” systems – software is not an exception. We think that our new software, written in a new and superior language, using the best methods and latest practices, will live forever. But this is not the case. Many “old” projects were once new projects that were written according to the latest fads – they aged just the same.
The relentless accretion of code over months, years, even decades quickly turns every successful new project into a legacy one.
– Grady Booch
People often resist the idea that software ages, because if our program is correct today, there is nothing about time itself that will change that correctness, and text itself doesn’t fade or blur or rot. Practically, however, this ignores a number of factors that cause software to age.
Ultimately, we can condense aging into two distinct types, which serve as a “one-two punch” that can lead to rapid decline in the value of a software product
- Lack of Movement – Failure to keep up with the changing environment and needs (related idea: Bit Rot)
- Ignorant Surgery – damage caused by changes made to keep the software “up to date”
Firmware ages more quickly than software due its dependence on hardware, so embedded software developers need to pay special attention to this problem.
The “symptoms” of aging include:
- Software “Weight Gain”
- Rapidly rising maintenance costs
- Inability to keep up with others
- Reduced performance
- Decreasing reliability
These symptoms are perhaps better viewed viewed as costs of aging. On top of the costs above, as Dr. Parnas points out, old software often cripples its once-proud owners when it previously gave them market share and a valuable reputation. This happens because:
- Increasing effort is required to support the software
- Younger competing products move faster and take customers away from you
- There is less energy available for keeping up with competitors
Sometimes software descendants take over, but more often they do not. Death (abandonment) can be postponed, but it is not inevitable.
All hope is not lost, however: there are ways to slow down software aging, such as designing for change. Averting aging is the most important goal for the long-term health of your system, so do not ignore these practices. Since we know that aging is inevitable even with efforts to avert it, you also need to plan to replace your product from the very start.
References
-
Software Aging Paper by David Parnas
The authors and owners of new software products often look at aging software with disdain. They believe that, if the product had been designed using to- day’s techniques, it wouldn’t be causing problems. Such remarks remind me of a young jogger scoffing at an 86 year old man (who, unknown to the jogger, was a champion swimmer into his 50’s) and saying that he should have had more exercise in his youth. Just as we will all (if we are lucky) get old, software aging can, and will occur in all successful products, We must recognise that it will happen to our products and prepare for it. When old age arrives, we must be prepared to deal with it.
-
Software Aging – Why it happens and how to reduce it by David Parnas
Well-designed software will age more slowly
Designing for aging is our most powerful weapon
-
Software Aging Slides by David Parnas
“Programs, like people, get old. We can’t prevent aging, but we can understand its causes, take steps to limit its effects, temporarily reverse some of the damage it has caused, and prepare for the day when the software is no longer viable. … (We must) lose our preoccupation with the first release and focus on the long term health of our products.”
— D.L. Parnas -
David Parnas on Education, Software Aging, AI and Agile Methods
This year you are opening Voxxed Days Belgrade in the role of a keynote speaker. What do you plan to share with the audience — can you give us some insights?
I am going to address a strange sounding topic, “Software Aging” In my lengthy career I have watched a great many software systems start out with great expectations but eventually receive the negative label “legacy software”.The software was modern and easy to use when it was new but, after many changes had become clumsy to use and very hard to change.
There have been a few exceptions but this “aging” keeps happening. When the new projects were started, nobody thought that they would become a burden to their owners. I think failure to expect the problem is the source of the problem.
If we remember that software, if successful, will age, we can design it in ways that slow that process down.
I sense that I will be speaking to people developing new products in a rapidly developing market and I want to help them to plan ahead and prepare their software so that it will remain fit for use and maintenance over many decades.
-
The Pragmatic Designer: The Rituals of Iterations and Tests by George Fairbanks
“Is your project a technical zombie? If you see any of these, consider them to be warning signs:
• The codebase reveals ideas from early iterations, like a skateboard.json data structure despite the product now being a car.
• When developers talk about the problem or solution, the terms they use are different from what you see in the code, and developers mentally translate those ideas.
• You know what refactorings to do, but the effort seems too great.
• The design has been evolved into something that nobody would have created deliberately.
• Newcomers to the project must, in effect, relearn the history of the project to understand the code.
• The system lacks names and types that largely explain the problem and solution.
• It’s hard to state universal truths about the system, like “All customers are stored in the customers table, and only in the customers table.”
• Few developers can deliver an impromptu chalk-talk about how the system works.” -
Linking Modular Architecture to Development Teams by Martin Fowler
Despite the best of intentions, software often deteriorates over time, both in quality and performance. Features take longer to get to market, service outages become more severe and take longer to resolve, with the frequent result that those working on the product become frustrated and disenfranchised. Some of this can be attributed to code and its maintenance. However, placing the blame solely on code quality feels naive for what is a multifaceted issue. Deterioration tends to grow over time through a complex interplay of product decisions, Conway’s law, technical debt and stationary architecture.
-
Timeless Laws of Software Development by Jerry Fitzpatrick
Ongoing development is the main source of program growth, but programs are also entropic. As they age, they tend to become more cluttered. They get larger and more complicated unless pressure is applied to make them simpler.
Programs automatically enlarge as features are implemented. However, first-rate developers take the time to make the code leaner and cleaner. When developers add code without improving it, the result is unconstrained program growth
-
Grady Booch
The relentless accretion of code over months, years, even decades quickly turns every successful new project into a legacy one.
-
Feature Creep by Seth Godin
Features are useful (that’s why we call them features). And yes, serving the underserved and the unseen is important. But creep cannot continue forever. At some point, there’s system bankruptcy and the cycle begins again.