This question already has an answer here:
- When is a BIG Rewrite the answer? 25 answers
Let's say I have a big, wonderful set of integration tests for my product. It tests anything and everything that we need to test. And after the product passes all these tests, we take a look at the source, decide it's complete garbage, and start from scratch. Is this a good business decision?
I fully acknowledge that no set of integration tests is perfect, and there are always time/budget constraints to be considered, but for the sake of this question we'll put those aside. Let's look at the benefits.
If our code base is 5 years old and written by the early programmers in the company who were learning as they go, and now we have "experienced" programmers who can make the code more maintainable. Yes, some may need ramp-up time on domain knowledge, but I'd argue writing from scratch would help develop this knowledge faster and more completely.
If the existing version of our code uses some core library that is "outdated" and performs badly in all scenarios, and replacing it wholesale will take 10 months and rewriting it with the shiny new thing will take 6. Seems like a no-brainer, right?
There's plenty of other "good" reasons to rewrite a product, but Joel's point is that you're bound to make the same mistakes that the previous product already outgrew.
But what of tests? If I have a way of testing a product that's not tied to the code itself (for instance, integration tests), doesn't that ensure that those potential mistakes are caught early?
Assuming you have a way of verifying behavior and output easily, especially with the tools available today, is starting from scratch still a bad idea?