Why legacy code rewrites are the hardest job in software

Thinking about a big rewrite? Don’t do it.

We get it. Legacy codebases are often like tangled mazes, with convoluted logic, outdated practices, and patches upon patches. Navigating through such complexity can be akin to searching for a needle in a haystack, making even simple changes a Herculean task.

Years of band-aid fixes, quick hacks, and expedient solutions accumulate as technical debt in legacy systems. This debt accrues interest over time, slowing down development, increasing the risk of bugs, and impeding innovation.

A rewrite sounds like a clean slate and a chance to architect the new system from the ground up, incorporating modern design patterns, technologies, and best practices.

But rewrites have a bad reputation for good reason. In most cases, the most expensive thing you can do in software is rewrite an entire system. It’s time-consuming and often causes more headaches and risks than it's worth.

The alternative is to unwind your legacy systems instead. Sometimes, incremental improvements or targeted refactoring efforts can achieve similar outcomes as a rewrite – but with far less disruption and risk.

If you’re considering a rewrite of your legacy codebase, it's crucial to carefully weigh the costs, risks, and benefits before investing.

Over the last 12 years, Test Double has helped clients with both solutions: renovating a legacy codebase and large-scale rewrites. Here’s some of what we’ve learned.

(Prefer to skip straight to a phone call or personalized advice? Contact us now.)

When legacy codebase rewrites are worth it

There are exceptions to every rule, of course. There are good reasons to rewrite, and there are times when it's the strategic business choice.

Some of the reasons it may make more sense to rewrite include:

• If the system is using outdated technologies, and it’s difficult to attract, onboard and retain developers who can support those technologies.
• If there has been significant change in or expansion of the project's scope over time, to the extent that the original codebase no longer aligns with current business objectives.
• When the accumulated technical debt (due to years of band-aid fixes, quick hacks, etc.) becomes so substantial that it outweighs the value of the underlying business logic.

A great example of when a rewrite made sound business sense:

In order to power its next generation of products, Cars.com decided to retool its systems for a modern cloud infrastructure and to turbocharge development with Elixir and Phoenix. We heclped them with that rewrite, which enabled them to realign their technical team with a more modern software development culture.

Why rewrites are so hard (and expensive)

A rewrite doesn’t seem like it should be that hard. After all, you have the source code you can look at to understand how the old thing worked and what it produced.

Here is a rundown of why rewriting is actually one of the hardest jobs in software:

Complexity overload: Software systems tend to become more intricate over time. They're like a tangled ball of yarn; trying to untangle one part often knots up another. This complexity makes it difficult to foresee all the repercussions of changes, leading to unexpected issues down the line.

Legacy dependencies: Many systems rely on older technologies, libraries, or frameworks that are no longer actively maintained or well-documented. This dependency web can trap you, making it arduous to update or replace components without causing ripple effects across the entire system."

Lack of understanding: Often, the original developers who built the system may no longer be around. This creates a knowledge gap where the intricacies of the codebase are lost in translation. Without a deep understanding of why certain decisions were made, it's challenging to rewrite without introducing new bugs or inefficiencies.

Scope creep: Rewrites have a notorious tendency to balloon in scope. What starts as a simple update can quickly spiral into a massive overhaul as stakeholders add new features or requirements along the way. Meanwhile, unused features are never culled from the system. We assume everything needs to be migrated, when the reality is that a fresh perspective on the problem can find a simpler solution.

Testing nightmares: Comprehensive testing is crucial for any software project, but it becomes especially critical during rewrites. Unfortunately, if the system is a nightmare being considered for a legacy rewrite, chances are the test suite is in even worse shape. That means little to no confidence you can perform the rewrite until you build up a set of automated tests that validate its current behavior. This can be labor-intensive, especially if you haven't done it before. If you do find that a rewrite is necessary, Test Double uses this approach and can apply it to help lower the risk of your rewrite.

User experience disruption: For end users, the transition from an old system to a new one can be jarring. Even with the best intentions, changes in interface, functionality, or performance can lead to confusion, frustration, and loss of productivity. Further, rewrites driven by engineers based on the perceived functional needs of the codebase are risky. Product managers need to lead the effort to clearly define the functional requirements needed in the new platform. This is critical to cull unused features, so that the codebase is simple and maintainable.

Code area lockdown: Rewriting a complex element often requires a development freeze on that specific area of the code. The intricacies of the overhaul make it challenging to integrate multiple changes concurrently. This means other potential enhancements or bug fixes in that region have to wait, causing the evolution of the overall system to stagnate.

Software standstill: Pausing the development of existing systems to focus on a rewrite can feel like slamming the brakes on your revenue engine. This interruption in delivering new features or improvements can impact your competitiveness and customer satisfaction.

No matter what path you decide – rewrite or remediation – it’s important to first assess what caused the system to deteriorate and address those issues before tackling the codebase.

Neither a rewrite or renovation will address the root cause. If you use the same process and culture to create a new system, you are likely going to just have another legacy codebase in the next few years. This is another reason why renovation or remediation is a longer-lasting approach.

How to decide to rewrite vs. renovate

We can help assess on a more personalized level what works best for you, your codebase, your team and your business objectives.

In the meantime, some factors to consider:

• What are the main issues you want to solve with a rewrite? If it’s an inability to pivot or try new product ideas, we’ve helped clients adopt new processes like Shape Up to enable experimentation through their release process.
• Is opting for a rewrite instead of refactoring a strategic move to capitalize expenses? By pursuing a rewrite, can the development effort be classified as a capitalized expense, potentially offering financial advantages? Furthermore, if functionality extraction and refactoring are integrated into broader product enhancements, can these activities still be considered for capitalization?
• Is your legacy system costly to run? We’ve helped clients reduce their infrastructure spend, optimize database costs and improve application server performance to reduce operating expenses of a software platform.

A free consultation: To write or not to rewrite?

Rewriting and renovating legacy code can both feel scary – but we’re here to make it as seamless as possible.

We can help assess your current codebase, challenges and business objectives to help you decide the right solution for you, your team and your business. Contact us now for a free consultation.