Ah, this old chestnut again. Just because Joel said it, doesn't make it true. Granted, the line between "refactor aggressively" and "rewrite" can be pretty blurry at times.
Granted, the line between "refactor aggressively" and "rewrite" can be pretty blurry at times
Not at all. The line isn't blurry in the slightest. In the "refactor aggressively" case, the code is continuing to run while you make the changes. In the "rewrite" scenario, you start with a blank page, and don't have an even minimally functioning system until you build enough of it to get to that point.
In my experience, the advantages to the former approach cannot be overstated.
> In the "refactor aggressively" case, the code is continuing to run while you make the changes.
I've seen (and done) plenty of refactorings that involved rewriting large parts of code and/or leaving things in a non-running state for a while. I've also seen (and done) rewrites that involved liberal re-use of code from the previous code base.
I think that's an overly narrow definition of "rewrite". In fact, I'd argue that piecemeal is the smart way to go about a rewrite, if that is at all possible. In which case the rewrite is just an aggregate of refactorings.
That "narrow" definition is the one being used by Joel, and the other authors who have weighed on in the debate. A rewrite isn't an aggregate of refactorings-- for the purposes of this debate, it is the opposite of an aggregate of refactorings.
