F**k Legacy Software and Technical Debt it Creates

Hear me out: Legacy is toxic. I’m not talking about your cultural heritage or your family tree. I’m talking about software, development practices, business decisions and often political decisions.

I am a software engineer by trade, with 20 years of experience across over thirty clients in various domains. Building and architecting complex software systems is my bread and butter. I also run my own product, a vastly different beast from professional services but, incidentally, plagued by the same pest:

Legacy.

How I Maintained Legacy and "Shame on Me"

With a hand on my heart, I’ll admit to my own failures. In the past, I worked as a search and reporting engineer, eventually leading the data team at a sizable SaaS company that processed tons of emails and other auxiliary information. We maintained a hefty cluster of Apache Solr instances.

Every two years, we went through a painstaking upgrade process as older versions reached End of Life or new performance/security requirements emerged. Each upgrade took months of testing and rewriting due to breaking API changes. A lot of the problems we faced stemmed from our insistence on replicating old patterns.

In hindsight, breaking away from legacy and moving to Elasticsearch would have brought major benefits in the areas where we suffered the most (reliable replication, node placement, observability, etc.). Similarly, working with slow and unreliable Amazon compute instances instead of moving to dedicated servers and bare metal cost us a lot of time in support and maintenance tasks that could have been spent developing new features. The legacy of organizational decisions—like "we use EC2 for everything"—caused numerous sleepless nights and a ton of anxiety.

That’s an example on the macro scale.

On a micro scale, we—software engineers and operations folks—make legacy-driven micro-decisions daily.

For instance, imagine there’s a new requirement, and you end up adding a new field to an existing database table. How often do you regret not updating the data structure or making breaking changes that would be more suited to the task, even if it comes with the cost of migration? I bet you’ve faced issues like that more than once in your career.

Legacy issues are pervasive—from small libraries and medium-sized SaaS businesses to large corporations, where they are most prominent. Challenging the entrenched status quo demands courage and political capital. If your boss has earned a position that allows them the power to be bold, stick with them and help them succeed. You’ll have a wonderful place to work, learn a lot, and tackle interesting projects. And if opportunity arises, become a boss like that yourself.

Don’t change or rewrite everything haphazardly, but also don’t fear change when you can prove the benefits of it.

Operating Systems – The Mothership of Legacy, Until It Isn’t

Legacy goes even further. Take this little operating system called Linux. Richard Brown, a former maintainer, made a compelling argument¹ against stable and LTS releases. Advocating for rolling releases like openSUSE Tumbleweed and MicroOS, Richard said, “Security and stability cannot be achieved by standing still,” and “In order to change any ONE thing, you must be able to change EVERYTHING.”

Want a more consumer facing example? Apple made bold moves from PowerPC to x86 and now to ARM, each time making clear-cut migrations. The execution wasn’t always perfect, but in hindsight, most would agree that it worked beautifully in the end.

Meanwhile, Microsoft has made small incremental changes in its migration to ARM. We’re currently witnessing their third foray into ARM, and this transition too has had a rocky start. The much-hyped Snapdragon X Elite chips are getting great reviews, but it’s Microsoft’s software legacy—and the fact that ARM is still a second-class citizen to x86 on Windows—that puts the whole transition in question.

Beyond Software

It’s not just software. Legacy and entrenched ideas hurt business processes, governments, and social contracts. Whether you live in a conservative country or a socialist economy, you face massive inertia to change every day.

As individuals, we’re capable of taking risks and plunging into the unknown. But when participating in teams, organizations, or government bodies, we fall into herd mentality, which stifles our appetite for risk.

We surrender to incremental changes, fearing breaking with the legacy.

Why We Celebrate Small and Fear Radical?

Open any self-help book, any productivity guide, and it will be full of checklists, to-do guides, and so on. Everything has to fit in a 25-minute Pomodoro. Bad advice? Absolutely not. But somewhere along the lines, we misread the instructions. These ought to be applied tactically, to manage discrete parts of our day, not to drive our strategic goals. That 25-minute Pomodoro will help you focus on writing a few tests, sure. But if your goal is to tick off 25-minute chunks and call it a day, then you won’t go far.

Making radical change is not always glamorous. It upsets people. It might even expose dead weight and lead to a reduction in headcount.

It reverberates like the old adage: Nobody gets fired for buying IBM. Sure, you might not get fired for polishing the pile of mud that’s been sitting there for the last 10 years. But on the other hand, your business might not be alive in a year or two.

So...

F**k Legacy!

F**k it and tear it down with confidence and expertise. Too often we tip-toe around issues that deserve decisive action.

I’m not saying delete every piece of software and rewrite everything when it’s time for an update. I’m saying don’t refuse to implement drastic changes just because they’re difficult.

You can’t change a data structure to improve performance because it requires migrating 20TB of data? Yes, you can! Build a plan for how to do it and execute.

Can’t upgrade your system/network/whatever because of a legacy system still running on Windows 3.1 (not joking)? Start a new project to re-implement that bottleneck and earn your organization massive savings eventually.

Incremental changes and keeping legacy systems on life support are only safe until they aren’t. I bet the operators at Paris Orly airport wished they’d replaced Windows 3.1² (see, I wasn’t joking) long before it glitched in 2015.

Change is good.