[hn_throwaway_99]

Actually, the more experience I get, the more I think Joel was wrong. Like anything in software, I've had the experience that there are good ways and bad ways to do rewrites. Start with the reasoning for doing it:

Bad reasons: "The code is messy", "It's written in language foo while all the cool kids are using language bar these days", "It's slow".

Good reasons: "The architecture is too tightly coupled now and it won't scale without untangling major pieces anyway", "The lack of our forward velocity is directly related to problem XYZ in the code, and here is how a new architecture would fix that."

In other words, I feel like I can sniff out bad rewrites now, which are generally lack a sense of focus and a true, enumerated list of problems with the current code base. Good rewrites have clearly delineated benefits that the rewrite will bring, stuff that brings measurable value, and show that the rewrite will bring things better and more cheaply than what's possible with the current codebase.

[entha_saava]

> Actually, the more experience I get, the more I think Joel was wrong.

There is no black and white in software. Joel writes from a viewpoint that's not always applicable to all of us.

[hn_throwaway_99]

> There is no black and white in software.

That is my whole point. The title of the blog post is "Things You Should Never Do", and it highlights "They did it by making the single worst strategic mistake that any software company can make." (emphasis Joel's).

Doing a rewrite may be a horrible mistake, but Joel was just wrong advising no company should ever do it. Lots of companies have done that, quite successfully.