Refactor or Rebuild

In the land of legacy code, many teams discuss whether they should refactor the existing application or rebuild it from scratch. But the answer to this problem is more nuanced than many would like to admit.

What is Refactoring?

I’ve previously written about what refactoring is and why it is a valuable investment. In short, refactoring is where code is changed so that it has a higher quality, but without changing any functionality.

This higher quality usually allows teams to pay off technical debt, prepare for new features or adhere to new standards for example.

What is Rebuilding?

Rebuilding an application is the act of building a new application from the ground up, so that it can later replace the old software.

Depending on the size of the old application, and the knowledge and experience of the team, this can take quite a while. Often, the existing application still needs maintenance or new features while the new code is being written.

It’s Not That Simple

There are other options than just simple refactoring or rebuilding.

One option is to extract existing features into new applications and “decommission” the feature in the old application. Whenever the old application needs pieces of this feature, it will have to call out to the new application. This approach is called the Strangler pattern and is often used to evolve a single large application to microservices.

Another option is to halt development of the old piece of software and add any new features to new applications. This also requires some integration between the new and the old application. And it usually only postpones the more significant work of refactoring or decommissioning the old software.

Never Rebuild?

You might have heard people say that rebuilding is bad.

The reason rebuilding is a huge risk is because it is often underestimated. It’s unrealistic to expect to replace an application that took 10 years to build and fine-tune in a few months. Rebuilding usually takes longer than expected.

But there are cases where rebuilding could be necessary. When there is no longer support for the underlying platform for example.

Just make sure you know what you’re getting into. The existing application contains all kinds of specific knowledge to handle edge-cases that your users may depend on.

On the other hand, there may also be functionality that is no longer necessary. But how sure are you? Your team will have to be careful, critical and experienced.

Why Refactoring Is Preferred

If you can, prefer to refactor.

The existing application is important to your business and with refactoring, it can keep on servicing its users. You can avoid dropping support for the edge-cases.

You can still add new features, though if the technical debt is really bad, I suggest seeing if you can move the new features to new applications.

It might not be as attractive, but refactoring is usually the cheaper option. In most cases, it is possible to steadily improve the quality of the code over time.