Link Details

Which does everyone prefer? Myself I tend to side with refactoring simply because rewriting software is a usually large risk where you're hoping the software you end up with is much better than the software you've currently got. With refactoring you can work out the kinks over time and create a more polished product in the end.

Then again, I suppose a lot of it depends on the architecture of the project to begin with, not necessarily the code. If terrible database design choices were made and an obscure programming language used then maybe it might be time to look at rewriting.

Nice article. Even if it overgeneralize a little bit.

Some good points in there. The black line (rewrite) should probably have gabs in it, in that the software is usually utterly unusable and won't compile for a while during the rewrite. In practice, rewriting works for me early in the project when perhaps I don't have many unit tests in place. Let's face it, we rarely get it right the first time - after version 1 and 2 we're usually a lot wiser about how version 3 should be implemented.

If it isn't an obvious architectural problem then I think it shouldn't be fully rewrited. It is almost always better to refactor and then rewrite some ugliest parts.
Personally, I like the XP approach when re-factoring is a part of your every-day development process. Sooner you start the refactoring - lower the risks and the cost.

Often when you rewrite, you're bound to make a lot of the same mistakes again.

Yes, you may be more knowledgeable about the general architecture and main features, but the devil is in the details. All those afternoons you spent hunting down some obscure bug that occurred as side effect from some infrequently executed business rule. Believe me, you have long forgotten about that, and only when it rears its ugly head in production do you suddenly, but still vaguely, remember it...