Risks of Older Code

Old technology runs the world. No matter how much you’ve kept up on newer technology, you’ll find some seriously deprecated stuff floating around out there. Many times, especially earlier in your career before your hourly rates are too high, management will try to convince you to work on “legacy technology”. Sometimes the technology has some good points. While we’re not in favor of just throwing out old stuff because it’s old, older technology does come with a lot of downsides, especially for those not experienced with it. For one, it makes it harder for you to get a job anywhere else, which can mean that using older technology is a career-limiting move. For another, older technology may have been superseded by a newer version of the same technology, making it harder to get technical support. Finally, older technology might also limit your development options in ways that add a lot of work, work that management largely won’t understand. While many powerful systems have been built with older technology (and are adequately maintained), you’ll often run into situations where older technology is being used in a business, simply because of inertia, or because someone “used silverlight once and never again” {Will has a story}. People in general have a bias towards things they know and understand – it’s one of the reasons civilization works as well as it does. People can reason about things more easily when there are fewer variables involved. However, in technological professions, the “old and established” might better be understood as “the crusty and barely working”. Our job is to speed up and improve processes to the best of our ability – old technology can often get in the way of this for a variety of reasons. Further, the businesspeople in your company will not understand when you try to express why the software is getting in the way – they just assume we’re whining (and we are sometimes, to be fair). While older technologies can definitely work well for the purposes for which it was designed, we are frequently confronted with situations that the original authors of any technology didn’t consider. We have a security landscape that, at best, could be characterized as a cross between a dystopia and Idiocracy. Every day, more demands are placed on old systems, with new requirements for reporting, compliance, accessibility, integration with third party systems, or even compliance with new security restraints. The speed at which things change is always increasing, and we often find ourselves staring at our screens, realizing that the software we are maintaining today will not survive an upcoming event horizon. There is hope though – the newer a technology is, the more likely it is that someone else has already done at least some of the legwork required to bring it up to snuff. However, we can’t actually express it this way to management. Instead, as developers, we have to learn how to explain things to business people in a way that convinces them, rather than trying to explain it to them as if they themselves were developers. To company leadership, outdated software doesn’t look like a real problem. Instead, they treat it like an asset that is already paid off (instead of the liability it is). The problem with the way many software developers advocate for newer technology is that they do it from the perspective of a software developer, rather than the perspective of a business owner. While there are plenty of merits to using newer frameworks and technologies to get the job done, most of the things that developers like about newer frameworks don’t matter at all to the people in charge. However, if you can characterize the risks in terms the business people can understand, you’ll have a lot better luck convincing them to let you use newer technology to do your w...