[macspoofing]

>I've never bought into Spolsky's vision that re-writing code is poor strategy.

I think it's something that's true in general but false in some specific cases. Rewriting involves spending enormous time and resources to at best standstill, and at worst move backwards ( chances are your re-written product will be poorer in features, and initially buggier than your old, stable, battle-tested version). For smaller companies, it is a death knell.

[jroseattle]

Yes, very true. Although I'd like to add some context.

> Rewriting involves spending enormous time and resources to at best standstill, and at worst move backwards ( chances are your re-written product will be poorer in features, and initially buggier than your old, stable, battle-tested version).

There is plenty of evidence that this has happened in many places and with many companies. A very real scenario that's played out before.

I'd say those scenarios were not well-executed. If the outcome of a re-write is "standstill", the re-write is pointless. There is no justification for proceeding with it.

However, if "standstill" equates only to user-facing features, chances are the re-write is to address critical issues elsewhere (I get the impression that was the situation with the OP.) In that case, "standstill" doesn't apply. It's simply a matter of deciding whether or not the effort and risk justifies the reward.

To my main point, Spolsky's hard-line essentially says re-building your application from scratch is bad strategy. I think it is short-sighted to draw that line. I prefer to exercise judgment and draw on the resources at my disposal for the given situation. I presume many others do as well.

[macspoofing]

>Spolsky's hard-line essentially says re-building your application from scratch is bad strategy.

I don't think Spolsky's position is as "hard-line" as you think it is. I always took it as a very very strong "rule-of-thumb". Every time a rewrite is proposed, it should sound warning bells in all stakeholder. And we're talking about a clean-room rewrite, and not a sub-module rewrite. Spolsky has no problem with rewriting and re-architecturing sub-pieces of an application.

Twitter is a great example of Spolky's philosophy. They had a big architectural and technology problem with Ruby and RoR, but they didn't do a clean-room rewrite with Java. Instead they tackled one sub-component at a time, and now they have something that rocks, but still allowed them to keep the time/code investment they made originally. Just as well, it allowed them to incrementally 'upgrade' their service.

[gnaffle]

I think the big danger Spolsky warns about is the "stop working on the old code and spend a year doing a complete rewrite". Many very smart people have underestimated the risks in doing that and the time it will take, while overestimating the benefits.

A smarter approach is to rewrite parts of the code. Apple has done that with many apps (and even iOS is OSX with a new UI/API on top). Linux has had many patch-by-patch rewrites as well. With a webapp, a "complete rewrite" still might leave most of the heavy lifting to the web framework, and you might be able to keep most of your HTML, CSS and JS.

I think the well-executed rewrites usually include launching an entirely new product while still supporting the old one. Adobe did this with InDesign (replacing PageMaker), Apple did this with OSX (the initial releases included OS9) and Microsoft did it with NT while keeping Windows 9X around.

[yuhong]

Yea, the WaSP was in 1998 petitioning Netscape to cancel Mariner, and unfortunately they caved.