To Refactor or to rewrite?

Some insights on refactoring vs. rewriting code — and the risks and consequences of a rewrite. Because it is not necessarily the cheapest option.

A ❤ FOR LEGACY

In this post we want to expand a little on the topic of rewriting vs refactoring a legacy system.

A lot has been written on that topic by very smart people, so maybe we can give a short refresher on this timeless topic. (For anything on the definition of refactoring, refer to Martin Fowler who has written the fundamentals)

We know that building something new is more exciting than caring for old stuff…

But some developers (usually the ones who never did a big rewrite) might underestimate the effort it takes to recover all old requirements buried deep in the code. Even when you have the old product owners at hand, who still remember why all the features where so important for the business “in the old days”, depending on the amount it might be hard to identify and prioritize the core features correctly. The majority does not have a documentation of their core business processes and the corresponding functions supported by the underlying software.

When you decide on the rewrite, you need to get all the stakeholders on board or you will most likely focus on the wrong “problems”. Arguments for the rewrite could also include the opportunity to refine and simplify the business side, instead of just re-implementing grown features…

But people who went through several rewrites argue that you should never rewrite your software.

What are the common characteristics of a rewrite?

• It takes much longer than the team have planned for, costing more money than budgeted
• From day 1 it feels like you’re behind schedule, because your business gets decelerated, while the market moves on
• Features were written over many years, but need to be re-implemented in less time now
• Forgotten implicit side effects and business edge cases along with complicated bug fixes need to be discovered again — hooray!
• The old system needs to be kept alive (maintained) in parallel.

So…why do developers tend to vote for the rewrite?

Joel Spolsky may have an explanation for this:

“We’re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We’re not excited by incremental renovation: tinkering, improving, planting flower beds.

There’s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming: It’s harder to read code than to write it.

This is why code reuse is so hard. This is why everybody on your team has a different function they like to use for splitting strings into arrays of strings. They write their own function because it’s easier and more fun than figuring out how the old function works.”

The thruth is: you don’t control the rewrite, it controls you. (Dharmesh Shah)

“One of the great things about refactoring is that you get to pick how much of your time you allocate to cleaning up existing stuff and how much you allocate to responding to new market demands. (And please spare me the excuses that you don’t have the discipline to refactor, you’re better than that). Should some massive change happen in your market (like a worthy new competitor), if you are refactoring a piece at a time, you have a fighting chance of responding. If you’re in the middle of a rewrite, you’re probably toast.”

We believe that a lot of legacy problems can best be solved by carefully refactoring.

Even major architectural changes can be done, without breaking or throwing away the code. An incremental rewrite of the most critical parts is a reasonable and cost effective strategy. While rebuilding piece by piece, you keep shipping functional software.

If you need guidance on how to work with your legacy applications, let us know!

For further reference, see a (shortened) version of our presentation on How to work with legacy code…

…or visit our website section Legacy on Rails

We can help you decide if it would be rational to refactor a big mess instead of starting from scratch. Because a rewrite is not necessarily the cheapest option.

Originally published at www.railslove.com.