Before you rewrite it

The common advice is to never rewrite a system from scratch. The reasons are real. Old code carries years of fixes for corner cases that nobody wrote down. A rewrite starts out clean, rediscovers those cases one by one, and soon has its own workarounds.

I don't think the answer is always no. It depends on things you can check before deciding.

The questions

• How often does the legacy code need maintenance and changes?
• How long does each change take on average? Is that tolerable?
• If you think your team can do better, what exactly would you do differently?
• Does the code follow a standard? Is it the standard your team uses today?
• If new people were hired to maintain it, is there someone who could explain how it works? Or would each of them have to figure it out alone?

What happened in my case

When I asked these questions about the apps my team maintained, the answers pointed to rewriting. An average change took three to four days. One change took two months.

For that last system, after a lot of discussion, we decided to rewrite it. The new version was ready in three weeks, with no shortcuts and no compromise on code quality. We went on to rewrite every app where the answers looked the same.

Robert C. Martin makes the point in Clean Code that disorganized code can cost a company a fortune, and sometimes the company itself. A rewrite that brings good fundamentals with it can pay off over the long term, and sometimes over the short term too.

So should you rewrite?

It depends. What impact will it have? How often does the code need to change? And what makes you think you, or your new team, can do better than the people who wrote it?

A rewrite is worth considering when you can say what you'll do differently and what it will save.