Dealing With Legacy: How Do You Decide Whether To Start Afresh Or Just Update The Old Code?
I haven’t met a software engineer yet who likes digging into someone else’s code to fix bugs or add new functionality. It is always a challenge to understand someone else’s work, even if the code is half-ways decent. Sometimes it can be quicker to just re-write the application from scratch. But not always…
From my own experience in the engineering teams at Microsoft know of numerous libraries and components in the Windows operating system that were built 10 or 15 years ago upon which masses of software now depend. Any time engineers try and touch a piece of those ancient APIs they invariably wind up breaking something. Some applications integrate with Windows on a byte level. Simply recompiling a DLL or API can wind up causing 3rd party software to fail. It’s no wonder that Microsoft programmers are highly reluctant to even touch those old libraries. Unfortunately, that just can’t be avoided sometimes when issues arise. Keeping this old code around can prevent making needed changes elsewhere in the operating system and security problems must be fixed no matter the compatibility risks.
How do you make decisions about whether to simply re-write old code from scratch or whether to roll up the sleeves and get dirty with updating the old stuff?
Is there a point at which ALL software should be rewritten to keep up with the latest conventions and technology? Perhaps the troubles with finding skilled personnel to maintain software written 30 years ago is just not worth the trouble.
On the other hand, if it ain’t broke don’t fix it. Why should old software be chucked out the window just because it is built using old languages?
This raises an interesting question about new software. How long should developers expect their software to be in use? Are there things that should be done when creating software the first time to ensure it will be serviceable and healthy 50 or 70 years down the road?
Right now my gut tells me that building software to last for a century is nothing more than a pipe dream. Things change SO fast in the software field that you can’t possibly anticipate future directions and even elegant code can become orphaned as new languages or platforms emerge. You might create the best architected code on the planet only to find that the hardware it runs on has become hopelessly obsolete 80 years from now, and that no replaceable parts can be found anywhere.
Software engineers truly are a breed apart. Civil engineers talk about designing bridges to last for 500 years. In software we are thrilled if our code can last for 10 years.
SEP Chief Evangelist
P.S. The Software Development Times is offering a free one-year subscription to their print edition to SEP members in North America. http://bit.ly/SEPsdTimes