Legacy Systems

18 February 02019

Pretty much everyone who has dealt with legacy systems knows the frustrations that they cause. And I’m not just talking about old code bases, I’m talking about things like city planning or laws or ways of thinking. Two things come together to create legacy systems: it being hard to update, and it being vitally important (in the minds of people who oversee it). If a system is easy to update and vitally important, it can be easily replaced with whatever’s state of the art. Conversely, if a system is hard to update, but not vitally important it can easily be scrapped when the cost of maintenance go above the benefits. Often legacy systems are accompanied by incumbents that make it hard to update, usually incumbents that helped to build it in the first place. Also, being hard to update doesn’t necessarily mean it’s technological or financial, social or psychological factors can make something hard to update. For example, I would classify the F-35 program as a legacy system, as a combination of sunk costs and political pressure by Lockheed Martin makes it nearly impossible to get rid of.

By virtue of being hard to change, as they age, legacy systems tend to create a lot of friction with people who use those systems as it becomes out of date or suboptimal. Usually people just adapt and learn to deal with the frustrations of interacting with these systems. There are two ways to overcome legacy systems, update them so much that they eventually become up to date, or make something new (sometimes blowing up the original in the process). As legacy systems get more entrenched, the 2nd option becomes more appeasing, and usually get invoked when some sort of disaster happens. Waiting until a disaster is unfortunately common to everyone, as people don’t really see the need to take action until there are visible consequences. Think about what legacy systems you interact with, what problems they solve, and what a better version of them would be.