Preservation Engineering: Snubbing Modernization and Transformation for the ‘Tried and True’

“If it ain’t broken, don’t fix it,” said Bert Lance, director of the US Office of Management and Budget during Jimmy Carter’s 1977 administration. Modernization may be a worthy goal, but it comes at a price that may not necessarily be worth it. Annual upgrades to the latest iPhone or computer chip may bring incremental improvements, but do you need it?

That’s part of the rationale behind ‘preservation engineering‘, a term that’s usually applied to the restoration of old building and homes. There’s one part sentimentality, one part practicality, and one part heritage behind the thinking. There’s the beauty of the classic trains and historical buildings that are restored and polished to their original states. And there is also saved money that might be better spent on something else.

Preservation engineering happens in software too. While the overall trend is to always move forward to new languages and apps that are suited and targeted to run on the latest hardware, upgrades can come at a significant cost that many businesses would prefer to delay for as long as possible. Delay is often the preferred path, especially when the existing software or application is heavily customized or integrated into other systems.

It’s always important to weigh any upgrade benefits versus costs and risks. Benefits usually include better security, new and updated features, and possibly more streamlined and efficient interfaces and processing. Costs include the money to install, test and deploy, the risk of upgrade failure, potential resistance to any changes from employees, the need to train staff on the new system, and the need to contend with possible bugs in new software.

Modernization ultimately will win out, but some things never seem to die. For example, preservation engineering is the driving force behind the long life of software languages like COBOL. Huge investments in the old software have made businesses reluctant to upgrade. Some have estimated that there are more than 200,000 billion lines of COBOL code out there in existing systems.

Scott Colvey, contributing writer to the Guardian, wrote in 2009 that “Cobol is to business what the combustion engine is to motoring: it has been around so long, and installed in so many places, that doing something different would be impossibly costly.”