rewrite, or refactor?

second system syndrome

Question: What begins with a "P" and ends in a "A"? Answer: second-system syndrome.

It starts with a PHP programmer (who needs to learn a lot), and ends with a bunch of JAVA consultants (who need to earn a lot).

The original PHP programmer and his Frankenstein brain-child embody the Generalized Peter Principle in action:

anything that works will be used in progressively more challenging applications until it fails Wikipedia

When the old ways of doing things break down, an opportunity emerges to move an organization to a completely new level of vision and quality.

In this window of opportunity, the phantom of a silver-bullet magic solution holds great appeal. Soon, the envisioned solution is overloaded to fix anything that has gone wrong before.

People who have designed something only once before try to do all the things they "didn't get to do last time," loading the project up with all the things they put off while making version one, even if most of them should be put off in version two as well. Wikipedia

the reality dysfunction

Those seduced by the "total rewrite" utopia are in for a nasty reality check. Wishful thinking does not solve real-world problems.

It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. Joel on software

I've seen it in my consultancy work. You return after two years. Everything has been rewritten from PHP into Java. You analyze the new system. And find the same old problems.

• They still have the same type of cascading failures where a hanging database connection crashes the whole cluster.
• They still don't do unit testing. Or documentation.
• They still do ad-hoc releases of insufficiently tested code without rollback capability.
• Application developers still don't talk to systems administrators.
• Systems administrators still measure systems performance, instead of application performance.

wetware 2.0

You don't solve a software problem by throwing more hardware at it. If you've got an I/O locking problem, buying a NetApp just makes the crashes that much more spectacular. What you need to do, is to re-architect your software to carefully avoid global lock contention.

Likewise, if you get stuck in a mess of crappy code, the solution is not to rewrite it all in a strongly-typed programming language. You can write globals-infested spaghetti code in Java too, it just takes longer. What you need to do, is to embrace development practices that empower you to get a grip and produce better quality software.

A good programmer isn't just good at writing code. He's also good at reading code. And he takes pride in testing code. Lots of very good programmers release software with a testing code line count that's higher than the actual production code line count. If you think that's weird, you need a wetware upgrade.

You can't break through to higher levels of performance and quality, by merely installing new technology. You'll have to change people and processes as well. A new mentality.

rewrite && refactor

Now, I'm not saying you should never rewrite. Migrating to a new technology platform can offer substantial strategic benefits. I'm saying you shouldn't rewrite for the wrong reasons. Like, to avoid refactoring your old code.

The choice is not whether to rewrite or refactor. The choice is between either: refactor, or else: rewrite AND refactor. Rewriting doesn't eliminate the need for refactoring. You'll have to either refactor the old code base, or maintain the new code. And in between, you'll have to maintain both.

Maintaining an aging code base, AND writing a new system, is going to be a huge drain on your resources. Your team is split and will run into delays. You'll have to plan and carefully execute a transition. Meanwhile, your competitors don't have your time-to-market problem and will try to steal your customers.

If you can stare this reality in the eye and still want to bet the firm on a rewrite, you may have a chance of succeeding.