[asdfj843lkdjs]

Sometimes during the initial phase of building a product YOU realize you're on the wrong road and it's actually faster to toss out what you've got and start over.

But what if it is years later, and you are gone and it's up to some new guys to do the rewrite?

Or in the words of Steve: A CEO who had lived through a debacle of a rewrite or understood the complexity of the code would know that with the original engineering team no longer there, the odds of making the old mistakes over again are high.

So I think you and Steve aren't really disagreeing. You're talking about the early time frame, when you are writing all the code. He is talking about the later time frame, when the company has grown and you are long gone.

[cageface]

Agreed. Rapidly chewing through prototypes in the early stages of a project is a great way to weed out bad ideas.

Rewriting stable production code, on the other hand, is almost always a mistake.

[kemiller]

Depends on what you mean by stable, and what you mean by rewrite. If your end result is buggy and unstable, it's sometimes worth using it as a rough draft and starting over. Ground up rewrites in a successful environment (which was the subject of the article) are usually wrong.

Planned, incremental refactoring or re-architecture can be quite beneficial if done right.

[cageface]

Certainly. Continuous & judicious refactoring is the best way to avoid getting into this fix in the first place and is also generally the best way to dig yourself out.