refactor legacy code.jpg Getty Images

To Refactor Legacy Code or Not to Refactor Legacy Code

Despite admonishing directives to refactor legacy code, letting old code be is sometimes the best course of action.

Legacy code is one of those things that developers love to hate. In fact, mention the term to a developer, and you’ll almost certainly receive a reply about why it’s critical to stop everything you’re doing and refactor legacy code now. But the fact is that it’s not always possible to refactor legacy code. Sometimes, you just need to live with it. And, while that may not be ideal, it’s not the end of the world.

In fact, there are several reasons why having some legacy code around is actually a good thing. Don’t believe me? Keep reading for a list of five positive aspects of legacy code .

1. Your Legacy Code Already Exists (and Runs)

The first thing that should be said about legacy code is that it’s code that already exists. It’s not something you have to go out and create. It requires zero effort or time commitment on your part to use it.

And, unless it is really broken, your legacy code also runs. You don’t need to worry about debugging it or doing extensive testing before it can be deployed. Those things were already done on the code a long time ago, so the directive to refactor legacy code may not make sense here.

In all of these respects, legacy code is better than newer code that doesn’t yet exist or hasn’t yet been deployed. Sure, modern code is better if you have it, or you have the resources to write it. But in many cases you don’t, and having legacy code is not a bad thing in those circumstances.

2. Legacy Code Works with Your Other Stuff

Chances are that legacy code also works pretty well with the other systems or platforms that run in your organization. After all, if the legacy code has been around for a while, it has probably been integrated fairly thoroughly.

The exception, of course, is newer systems that were deployed long after the legacy code was created, and with the assumption that the legacy code wouldn’t be around much longer, so there was no reason to worry about integrating with it. Those newer systems may not be compatible with legacy codebases. But I’d argue that fault for lack of integration in that case lies with the developers of the newer platform, not the legacy code.

3. Legacy Code Has Been Vetted in the Wild

Unlike newer applications, legacy code has been living in the real world for years. It wasn’t just deployed yesterday. If it had serious flaws, they probably have been fixed by now.

That’s no guarantee that the legacy code is free of serious security, performance or other bugs, of course. There could always be issues that just haven’t been discovered yet. But if I had to place a bet on whether a legacy codebase or a brand-new one is more likely to have a problem, I’d bet on the new code.

4. Legacy Code May Be Lighter to Run

Legacy applications were typically written in eras when computing resources were more limited, or at least more expensive. They were the products of a time before public cloud vendors started slashing their virtual server and storage prices. Or, if your legacy code is truly old, it’s from a time when everything ran on-premises, and infrastructure was limited in scale.

What that means is that legacy code often consumes fewer resources compared to modern replacements. By extension, it may deliver better performance running on modern hardware, or it may cost less to run in the cloud.

5. When Legacy Code Just Isn’t Worth It

Lest I be accused of suggesting that developers never update legacy codebases, let me point out that there are clearly instances where there is just nothing positive to say about legacy code.

If it is creating technical debt in significant amounts, legacy code should be replaced as soon as possible. Otherwise, it just costs you resources unnecessarily. Similarly, if your legacy code has known security or performance bugs, you should ditch it as quickly as you can (unless you can fix the bugs quickly). And if legacy code is missing critical features that prevent it from doing its job fully, that’s another reason to replace it.

Conclusion

Still, in some instances legacy code may not be as evil as you think. Sure, it’s not ideal. But legacy code actually offers certain benefits that the latest, greatest apps don’t. That doesn’t mean you should keep your legacy code around as long as possible--you shouldn’t--but it is a reminder that the world won’t end if you keep your legacy code around for longer than you would have liked.

TAGS: DevOps
Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish