Why it’s okay to let some code die

Christopher Laine
Jun 4 · 5 min read
Photo by Robin Frejd from Pexels

When I tell people about new architectures I’ve been working on, one of the first question out of teammates’ mouths is invariably: “Are we going to upgrade everything to this new architecture?”

It’s a fair question, but two things bother me about it:

  1. That there still exists this underlying fallacy among IT types that if you have a new architecture, everything from one or more old architectures MUST be migrated to the new one.
  2. More importantly, that even if this is the expectation, that everything is worth migrating.

Some code is just not worth saving

Most organisations I’ve seen which have been around for five years or more invariably have some piece of dreck software which no one wants any part of. I euphemistically refer to these as ‘The Ruins’.

The Ruins lurk away from everything else in a lonely, half-forgotten repo. It almost never gets redeployed, since it never gets fixed or changed in any meaningful way. Even when it does get any love, it’s always remedial. A patch here, a package update there. No one wants to own the damn thing, and whoever initially wrote it has long since bailed from the place.

What it does, it does badly, or in a way that makes little to no sense. It has too much weird loop-de-loop logic, or too many mapping layers. It is stuck on some long dead ORM, or written in some language no one uses anymore. It has bugs, but none worth fixing, since it’s stuck on some framework from 2010 or earlier.

The Ruins are out there, and it’s about time you admitted to yourself they aren’t worth saving and just abandon them.

Photo by Christoffer Engström on Unsplash

Just throw them out?

That’d be nice, wouldn’t it? If only you could.

( There is something deeply satisfying about nuking a nasty codebase, never to see it again. )

Sadly, someone somewhere is still getting something approaching value from whatever the Ruins do, so you can’t do that.

No, but what you can do is admit to yourselves that it is abandoned. Mark it accordingly. Throw up the “Beyond this point, thar Be Dragons” sign, and otherwise inform everyone to do absolutely nothing with the Ruins, sans pillaging it for anything it’s worth.

Plundering the Ruins: Get what you can, and get out

The Ruins are doing something. Sure, they are doing it badly, or on antiquated code, but they are doing something for someone. You can’t just throw the baby out with the bathwater.

What you need to do is work out what precisely the Ruins are doing, and for whom they are doing it.

Who gets value from the Ruins?

You need to work out who is actually still benefiting from whatever it is the Ruins do for your organisation. With older-than-old systems, there is often a pretty big disconnect between what people imagine is the value so-and-so is getting from it, and what they are actually getting from it.

Take some time and work out who / what still needs the Ruins. Find out why, what they do with it, what they need from it / don’t need from it. Really understand what value the Ruins bring to the table.

WRITE IT ALL DOWN. Don’t work by hearsay and word-of-mouth. Write down the processes and procedures which hook into whatever the Ruins does so that everyone can agree on what they need from it. This is the first step to replacing the Ruins with something better: Knowing what it’s replacement needs to do.

What are the Ruins doing?

Work out internally how the Ruins are providing value to whomever. This can be one of the most painful parts, as it means trawling through a lot of shitty code, working out a lot of bass-ackwards logic, and otherwise picking through the garbage to find your kid’s retainer. It isn’t pleasant, but you need to do so.

This helps you to isolate any rework down to specific portions of the Ruins. These are the portions we intend to plunder. All we want are those bits (be they direct code copies, or just logic we need to satisfy our use cases) which actually help in delivering value. The rest of the Ruins can rot, as we intend to eventually purge them from all memory.

Photo by Jayphen Simpson on Unsplash

Now that you are armed with the above information, you are ready to begin doing better than someone else did before you. You are going to build / buy something new to do what the Ruins were doing badly.

The most important thing to remember is that any such plundering of the Ruins is a “Like for Like” swap. You are building to initially replace the required value which the Ruins gave. Do NOT turn this into an improvement project of the value proposition. As closely as possible, you want to mimic the inputs and outputs of the Ruins, as this minimises your effort and risk. Don’t let anyone talk you into adding / refactoring features unnecessarily. This might be a seductive proposition, but trust me: It only ends in tears for you and frustration for everyone involved. You have enough on your plate doing a direct swap. Don’t make this any more difficult for yourself than is absolutely necessary.

Conclusion

In my next rant, I’ll take you through areal-world case I faced in such a plundering of the Ruins, and the strategies and tools we used to get a 100% bug-free implementation of our Ruins replacement.

Hope this helps

IT Dead Inside

IT is a cesspool, but its home

Christopher Laine

Written by

Writer, sci fi / Lovecraftian nutbag, "master' chef, gym rat, martial artist, Dungeon Master, and programmer. I cover all the useless bases

IT Dead Inside

IT is a cesspool, but its home

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade