The Big Rewrite

Unlike refactoring, a "big code rewrite" bulldozes an entire application and starts over from scratch.

Is it ever the right thing to do?

In a recent post, Steve Blank says no - never for start ups in a fast moving market (Startup Suicide - Rewriting the Code):

CEO’s face the “rewrite” problem at least once in their tenure. If they’re an operating exec brought in to replace a founding technical CEO, then it looks like an easy decision – just listen to your engineering VP compare the schedule for a rewrite (short) against the schedule of adapting the old code to the new purpose (long.) In reality this is a fools choice. The engineering team may know the difficulty and problems adapting the old code, but has no idea what difficulties and problems it will face writing a new code base.

I think the big rewrite is almost always the wrong approach to "fixing" software - even outside of startups. Rewriting is a form of engineering wankery that makes it easy to avoid the hard work - identifying, prioritizing, isolating, and improving selected subsystems or components of an application while keeping the business running. This appears to be the approach Twitter took some time ago when the service was falling over each and every hour. See the "Improving Running Components at Twitter" presentation and note it's not called "Rewriting Everything".