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 work, rather than legacy stuff.

Episode Breakdown

Security Updates come slowly, if free, or at a cost.

Companies that make software frameworks are incentivized to provide timely security updates for their recent software packages because those are the things they are actively marketing. They are less incentivized to do the same for older stuff unless it is attracting negative attention. While this means you might be able to get the vendor’s attention if you make enough noise on twitter, that isn’t necessarily a good strategy for a critical business system. You really want timely support.

This tends to mean that you either pay a premium for extended support if it is available from the vendor, or you pay in other ways (such as hiring expensive contractors and using other expensive software to close the gap). While upgrades to newer software versions may not be free in many cases, that doesn’t mean that it isn’t cheaper than staying with the “software you already paid for”, because it doesn’t come without continual maintenance costs.

As other software in your ecosystem updates, you have a higher risk of crashes and downtime.

Software doesn’t exist by itself. It relies on the operating system, drivers, APIs (both web and application level), databases, and underlying protocols in order to continue working. While possibly more stable than the software itself, on a long enough timeline, these dependencies will also change.

While you might have been able to pursue a gradual update path if you’d kept up to date with your framework, if you leave things alone, you may suddenly (and unexpectedly) find yourself having to do a lot of work for upgrades, simply because you are so far behind and some dependency is broken. Sometimes these upgrades also require effort from your potential clients. For instance, if you are using a hashing or encryption algorithm for passwords and the algorithm is deprecated, a day will likely come where the algorithm becomes extremely vulnerable. You may be forced to make your clients reset their passwords with the new algorithm.

Increased cost of maintenance

Software written on older frameworks costs more to maintain. If you want someone with a year or two’s experience in the framework, you are going to be hiring only more seasoned developers, who are going to cost more. You might think that you can get by with hiring junior developers and training them, but this only works well if you have seniors around who can actually teach them.

This also makes development jobs at your company into a bit of a dead-end position. Anyone taking that job is making it much harder for them to get hired elsewhere. You’ll either pay a premium for these people, pay a premium for high turnover, or you’ll end up hiring the bottom of the barrel.

Bear in mind that if your framework is out of date, it’s not just your developers that you will be paying. You’ll likely also experience other costly problems, such as turnover, low morale, and interpersonal issues among staff (especially if you hire a couple good people, pay them well, and then try to round your numbers out with low quality devs – your good people will get overworked.)

Decreased Productivity

Older frameworks tend to come with decreased productivity. Not always, but the cases where it isn’t are statistically insignificant. Improved productivity is one of the ways that vendors convince you to work with a newer framework, after all. In addition to difficulties with older tooling, older frameworks can often require a lot more effort to implement things that newer ones take for granted. That’s assuming that it’s even possible. If it isn’t, be prepared to hack around things.

Unless you are paying very well, using an older framework means that you won’t be hiring the top tier of developers, even for your lead positions, in most cases. This will almost certainly increase the amount of technical debt you have, as well as inefficiency in general. Higher turnover will also lead to a drop in productivity, as critical system knowledge leaves the building for greener pastures, either for better paying jobs, or for retirement if your framework of choice is old enough.

Compliance risks

Regulatory compliance is a major issue that business people tend to ignore if there is a tech component to it. However, the sort of compliance issues that you run into in tech can’t just be ignored until the last minute and then fixed by interchangeable consultants. It typically takes deep expertise in YOUR system to meet regulatory requirements.

Regulatory compliance can entail everything from your user interface all the way down to the underlying operating system. While third party components of your software are maintained by others, the results of that software are YOUR problem. If you have a compliance issue, the vendor is just going to tell you to upgrade. This can get even more complicated if part of your compliance requirements include things like audit trails that may not be in place in older versions of your dependencies. These can’t be (easily) reconstructed after the fact, and may not be re-constructable at all.

You may also find that newer frameworks do much of the legwork required for compliance, while legacy frameworks may require you to do the work yourself. This work can be substantial and could even potentially require legal counsel to be involved in your software development process to make sure you are compliant.

Dead Sea Effect with your development team.

Your development team also suffers when you use old frameworks. The better developers will leave, unless they are close to retirement or you pay them well above the industry average. Even then, it may not be worth it to them. Junior developers coming into your company will need a lot more time to ramp up, simply because they probably didn’t learn older frameworks in school. If you are using a particularly old framework, you may find the same to be true of your mid-level or even senior developers as well.

Any developer who has been with your company for a while knows that they will have a much harder time finding another job, which may cause them to hoard knowledge and even undercut their coworkers out of fear of becoming unemployed (and being unemployable afterwards). The point of this is, you are putting your employees in a bad position, and the people most likely to stay in that position are the ones who will do the most damage to your organization and your product.

Data “loss” due to outdated storage formats or due to difficulty exporting data

While less common than it used to be, you may find that older frameworks store data in a way that makes it harder to extract to use in other parts of a system, whether it is being used to simply extend functionality, or to actually replace the older system. You may also find that if you wait around long enough, that it will be difficult to move to a newer version of the SAME underlying framework. Most software changes the way it stores data over time. While vendors can be expected to make small updates stable and easy, they often don’t test as well with large version jumps.

This is true, by the way, of even the largest companies. Witness how even Microsoft Word sometimes can’t read files created in older versions of itself. While actual losses of data are fairly rare (but possible), it’s more likely that your data will simply become more painful and time-consuming to access.

Inability to integrate with newer software

As with productivity, interoperability tends to increase over time with most software. The older your software (including underlying frameworks), the more poorly you can integrate, especially with newer software. This doesn’t always mean that you CAN’T integrate, just that it ends up being a lot more work. This work can include the effort required to get around small, poorly-documented glitches (and potentially dealing with an anemic support process around them).

This problem extends to more than just the data interchange formats that are available. It will probably include things like security considerations (authentication/authorization) and lower level transport concerns (HTTPS, particulary around certificates and the like). You may be able to get around some of this, using some of the low code / no code integration tools we mentioned in a previous episode {August 12, 2021}, but the fix will cost both money and time.

Failure to meet accessibility requirements

You could easily argue that tech companies ignored many things for too long. Whether it is security, interoperability, or legal considerations, software companies often spend a lot of time catching up to what they SHOULD have been doing for some time. Accessibility is one of those things. While there are plenty of legal requirements around this, many software companies haven’t really been hit with this yet. But it’s almost certainly going to be a larger consideration soon.

Because accessibility is complex and such a huge cross-cutting concern, many software frameworks have started addressing these concerns at a framework level. Framework implementations tend not to be compatible with whatever you hand-rolled at work, so this can result in a lot of rework later on. If your company has clients who are suddenly surprised with accessibility requirements, you may find that you are suddenly surprised with them. If you’ve painted yourself into a corner by sticking with older software versions, fixing the problem may be untenable. You could even lose the client in the interim.

Inefficient business processes

All of the previous concerns lead up to this one. Older software can slow your company down, waste money, waste time, cause turnover, and generally do all of that in an undetectable fashion while you are defending it as being “cheaper than upgrading”. Inefficiency is not a small problem, even if the inefficiencies are small ones. They open the doors to competitors and if they pile up enough, they can cost you enough that you become unable to get rid of them. It’s like interest on a debt – eventually the interest becomes so high that you can’t pay the principle.

This inefficiency may look like something you can overcome, but much of it is not immediately obvious. A lot of the inefficiency has to do with your ability to respond to risks and opportunities as well, and you won’t know how bad it is until it is too late. Further, if you are far enough behind in your tech stack, you may not even be capable of seeing some opportunities, especially if your entire tech team is behind the curve in technology.

Tricks of the Trade

Just like old code and frameworks can hinder a business, out dated concepts and understandings can hinder you. The world is constantly growing and changing, especially in technology. While you can find a comfortable niche in many areas of development you still need to keep learning and growing. Even more stable areas of development require you to learn new ways of using the existing systems and structures to be able to interact with the faster developing areas. You are either moving forward or backward, if you stagnate and thing that you can stay comfortable in your knowledge you will actually be moving backward relative to the rest of the world. Remember that no matter what your company says, it is ultimately your responsibility to keep your skill set up to date. You are the one who will be using those skills.

Tagged with: , , , ,