Software rots. Age is unkind to it. Just as people acquire aches and pains over the years, code tends to run down.
Young programs are slight, sprightly things that respond like gazelles and eat little disk space or flash. Bugs and misunderstood requirements frustrate users, but few expect much maturity from adolescence. With time and tuning the code seasons and becomes a fully productive part of a business process or product.
By middle age, patches, improvements and creeping featuritus bloat the girth and hobble performance. The graying code slows and swells, though still satisfies users.
Continuing bug fixes and ever more features drive the software into old age. Now annoying glitches and oddly interacting components deliver at best arthritic capabilities. Only heroic intervention at great expense staves off the inevitable. Cancerous growths forks controlled by hundreds of poorly understood #ifdefs metastasize recklessly. Comment drift renders all documentation gangrenous. Deft surgeons remove chunks so infected they're useless and graft repairs onto essential organs.
The code acquires the moniker “legacy application,” that label reserved for a program that's still needed but is so old and decrepit that maintenance costs soar. Some companies have a culture that respects legacy apps. In most they're considered a burden supported by the lowest paid developers, who resent the impact on their lives and careers.
When the cost to modify the code exceeds the value to the customer the program is either pensioned off to unsupported status or is euthanized, eliminated from the company's product portfolio. Sometimes it's replaced by a direct genetic descendant, a completely new, rewritten package whose design is drawn from the ancestor's structure but which exhibits all of the desirable attributes of youth.
And then the process repeats, with each generation evolving towards a higher level of complexity, better suited to fit the new, changed nature of the computing environment, then aging, eventually being buried six bits deep.
What a terrific waste of resources.
Death is an inevitable part of all life cycles. At some point a program simply meets no need. The world changes and requirements disappear. But all too often we kill off the software because of the creaky joints; it's simply too difficult to maintain.
And that's an even more terrific waste.
Wise developers build the code from the ground up with robust DNA that's impervious to the damage caused by cosmic rays of real-world change. They create an immune system (documentation, structured code, extensible design) that bends to the inevitable assaults rather than brittlely collapsing.
But once launched the program is under the care of maintenance custodians, who might wreak havoc faster than the Ebola virus. Maintenance can be a careful process that applies wrinkle cream to defer the inevitable fate of the aged, or a process of rubbing soil into an already infected wound.
Legacy apps are often the core software that creates the bulk of the company's profits. Yet we dump support on the newbies who hack quick fixes, invariably breaking other features. They're untrained and inexperienced. Patches accumulate, each a little bit of ugliness layered on top of earlier mistakes.
Great maintenance people don't slap a poultice on the exposed wound. They grow a culture, determine the illness's root cause, and then inject exactly the right antibiotic. Healed, the patient recovers, with neither scars nor lingering infections.
The cost of great maintenance is high; but that of poor support is ultimately even higher.
How do you prolong your product's life?
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He's conducting a seminar about building better firmware faster in Las Vegas on Dec 10. Contact him at . His website is .
A good medicine against software aging can be summarized in two words: periodic refactoring.
Quick fixes under pressure is inevitable to any software created for profit. In between these crises, we take a deep breath,and clean up the mess by first clarifying the now convoluted and often conflicting requirements.
This is, of course, beyond the ability of newbies. On the other hand, I often find myself in a position to clean up the messin projects initiated by newbies.
– David Liu
The one additional factor in software aging is that the toolsets used to create the software are aging at the samerate as the product built with them. In some cases, the compiler suites and RCS systems that were instrumental in thedevelopment and support of a product disappear or loss support themselves, or can't migrate the newer operating systems. Idon't see too many Intel Blue Boxes anymore. Or CPM systems for that matter. Having worked at a electronic medical devicecompany, I have first hand experience at the problems of supporting a product that may be 10 years old. Even archiving thetoolsets used doesn't guarantee that there will be a working platform available even two years down the road. And in today'sworkplace, the more valuable resource in squandered, the replaced/irreplacable technical staff with it's acquired history andknowledge.
– Clayton Johnson
As usual, Jack hits the nail on the head.
I was once the “supreme being of discontinued products” at Motorola's now defunct Wireless Data Group. I had the thankless job of maintaining the embedded software in a line of radio data modems. In retrospect, I think it was to Motorola's credit that they had a clearly defined process, a budget and a staff (me) dedicated to maintaining the software in a line of discontinued products. Unfortunately, once I was labled as a maintainer my career got stuck in a ditch. I watched with envy as the signal processing guys worked on new airlink protocols while I got to develop test scripts that attempted to reproduce failures we were seeing in the field. I eventually quit the job and moved on to more interesting work.
The moral of the story: software maintenance is a critical but unrewarding activity. If program managers wish to keep good people involved in maintenance the burden of this work should be shared equally amongst amongst all developers.
– Hugh Shane
The integrated circuits that run software also “Rot”. After a chip is done designers are scattered to thefour winds leaving a few for bug fixes and support. After a while these are pulled off leaving only a support person(productengineer) and an overworked apps. engineer at best. After a while the fab the chip is built on begains to go down hill. Eventually the chip must either be moved to a new fab or killed, or re-designed for a new fab's processes(more bugs mightcreap in if it's at all complex) (Try getting a 4004 these days, or see if your 8051 code runs unchanged from one 8051vendor to another with each vendors unique peripherals for example) These days it is like building in quicksand, rather than anything firm. The problems are that much worse if you are doing something that isindustrial, avionics, marine, or other long lived product that must last 20+ years, but needs to use a high complexity fast microprocessor. Therejust might not be that much in the way of support after 20 years, or in the case of many of the platforms have evolved somany times that you've made a career out of doing chip, board, or software re-spins.
– William Murray
I'm in a dilema because I'm told “testing is expensive”. Whatever we change, we have to retest. That means thepressure is on to touch as little of the code as possible. Depending on the changes, that can encourage quick hacks insteadof proper reworking.
It seems necessary to convince management that maintaining good code is cheaper in the long run, despite the short-termhigher costs.
In general this phenomenon — short term costs, long term benefits — seems hard to sell to management.
– Craig McQueen