First, there are architectural problems. The code is not factored correctly. The networking code is popping up its own dialog boxes from the middle of nowhere; this should have been handled in the UI code. These problems can be solved, one at a time, by carefully moving code, refactoring, changing interfaces. They can be done by one programmer working carefully and checking in his changes all at once, so that nobody else is disrupted. Even fairly major architectural changes can be done without throwing away the code. On the Juno project we spent several months rearchitecting at one point: just moving things around, cleaning them up, creating base classes that made sense, and creating sharp interfaces between the modules. But we did it carefully, with our existing code base, and we didn't introduce new bugs or throw away working code.

What I said I advocated is shaking and restructuring, not a clean sheet rewrite. Much the same as Spolsky advocates in the passage quoted above. I agree with Spolsky's points, especially on large team projects.

My sense is that an initial code development project should have two or three clean sheet revs, but it is rare that I'll look at a rewrite after that, especially with code which has been through the mill with users. The only time I'm willing to consider that is when we're doing a complete architectural revamp, but, even then, I'll have my coders do a completion phase with the old codebase such that everything is consistently implemented in the old paradigm and tested.