Legacy code dangers: code is inventory

Inventory costs to keep, and this is true even when that inventory is code. For SaaS companies, it can be easy to hoard code for old features, old programs and old systems. You’ll find even the most advanced software houses in the world sheltering legacy code. After all, if it ain’t broke, don’t fix it, right?

Unfortunately, when it comes to legacy code, that adage doesn’t quite fit. The code might work, but that doesn’t make it workable for your team.

There are hidden risks to building products on old codebases instead of modernising your software. From security concerns to product instability, integration woes to explicit expense, we explain some of the dangers of legacy code.

 

What is legacy code?

The old joke in programming is that legacy code is code that works – even though nobody really knows why. In a more formal context, legacy code refers to code that is no longer supported. It might have been inherited from an old team, it might be written using an old language or under an older framework, or it might have been written without unit tests.

Think of legacy code as like those robust old devices of years gone past – devices that were built to last. Legacy code is old, it’s solid, it works, and it seems capable of chugging on forever. So, what is so bad about that?

 

Lost understanding

The problem with legacy code is that the older it gets, the more it becomes incoherent or difficult to understand. At one point, that legacy code no doubt made sense. Since then, it’s been worked on, expanded and patched up by developer after developer.

You’re left with a codebase that nobody knows how to maintain or upgrade. Developers fear messing with it too much, since it now has so many dependencies. They might not know where to start in tackling the codebase, and could even risk breaking something foundational if they try.

Plus, there’s the language barrier to contend with. As new coding languages are adopted, programmers that can use and understand your legacy code become scarcer. This means that people with those talents are often difficult to find and expensive to employ.

 

False illusions

Because it works, legacy code gives the illusion of stability. It’s tried and tested – it’s safe. But as time goes on and coding languages, practices and understandings evolve, legacy code turns into a growing mound of spaghetti code.

Updates and new features are piled on top of that legacy codebase. Inevitably, workarounds are employed to make the new additions work on dinosaur systems. After a while, you can’t change part of the code or fix bugs without something else breaking. You end up playing Whac-A-Mole with code, quashing one issue only for another to surface.

It’s now much harder to fix problems cost-effectively and quickly. This negatively impacts the quality of your code and, by extension, your product.

 

A lack of mobility

Legacy code isn’t just difficult to work with, it’s also dangerous from a competitive angle. When a code or technology is no longer supported, it won’t work properly with new apps, programs or hardware. This means that legacy code can hold your business back, as you are unable to evolve with emerging technology.

You know that your legacy code needs refactoring to bring it into compliance with modern standards, but the task is daunting. The risks and costs of updating are perceived as too big. You’ve invested in deploying that software, it feels counter-productive to change it. So, you fall into the no change trap.

Unfortunately, this means that instead of modernising, the codebase grows increasingly outdated and convoluted. You struggle to integrate with new technologies, and risk falling behind as that dead weight of legacy code drags you down.

 

Costs and aging platforms

It might feel like you’re saving money by not spending on updating your code. In reality, that might not be the case. One of the main risks of legacy code is that it can cost both money and resource to keep it running. Remember: as a software company, your code is your inventory, and your legacy code is driving up those inventory costs.

Plus, older codebases typically require older hardware and systems to run. This will drive up your costs, as obsolete systems are harder and more expensive to maintain. They’ll also extend your integration struggles. Once more, you could easily find yourself forced to use awkward workarounds and unstable integrations.

As Roger Guldbransen puts it: ‘Legacy code is a form of technical debt. And technical debt is never good’.

 

Security risks

The evolving threats of the digital age are another contributor to legacy code dangers. In our book The Conversation Engine, we write about the unprecedented scale of cybercriminals targeting business in the current digital climate.

Cybercriminals have new technology and faster computing speeds at their disposal. Attackers are armed with knowledge of the weaknesses in older systems – such as the systems your legacy code requires to operate.

Increasingly, they’re using this knowledge to cripple companies. We’ve all seen ransomware such as WannaCry earning media spotlight, and attacks have been suffered everywhere from the entire city of Atlanta to the UK’s NHS. Nowhere seems safe.

Couple these evolving threats with out of date (and insecure) frameworks and libraries, and you’ve a security nightmare on your hands. If you don’t update your code and systems, you become an easier target. Legacy code could be opening a backdoor to your business for cybercriminals.

 

Code is inventory

It’s easy to forget or ignore the costs of carrying code. Perhaps it’s viewed as a necessary evil. After all, your legacy code is tangible evidence of your company’s achievements and evolution. But that doesn’t mean it won’t hold you back. Your legacy code might have paved the way to modern standards, but it can’t improve without being updated.

If your code is your inventory, you can’t afford to neglect it. Update what you need, delete what you don’t, and do so regularly. Don’t be a code hoarder.

 

Useful links

The Conversation Engine

How do you deal with another developer’s bad code?

Feature creep: everything but the kitchen sink. Is your software guilty?