When to rewrite a code base from scratch

Question

I think back to Joel Spolsky's article about never rewriting code from scratch. To sum up his argument: The code doesn't get rusty, and while it may not look pretty after many maintenance releases, if it works, it works. The end user doesn't care how pretty the code is.

You can read the article here: Things You Should Never Do

I've recently taken over a project and after looking through their code, it's pretty awful. I immediately thought of prototypes I had built before, and explicitly stated that it should not be used for any production environment. But of course, people don't listen.

The code is built as a website, has no separation of concerns, no unit testing, and code duplication everywhere. No Data layer, no real business logic, unless you count a bunch of classes in App_Code.

I've made the recommendation to the stake holders that, while we should keep the existing code, and do bug fix releases, and some minor feature releases, we should start rewriting it immediately with Test Driven Development in mind and with clear separation of concerns. I'm thinking of going the ASP.NET MVC route.

My only concern is of course, the length of time it might take to rewrite from scratch. It's not entirely complicated, pretty run of the mill web application with membership, etc..

Have any of you come across a similar problem? Any particular steps you took?

UPDATE:

So.. What did I end up deciding to do? I took Matt's approach and decided to refactor many areas.

• Since App_Code was getting rather large and thus slowing down the build time, I removed many of the classes and converted them into a Class Library.

• I created a very simple Data Access Layer, which contained all of the ADO calls, and created a SqlHelper object to execute these calls.

• I implemented a cleaner logging
  solution, which is much more concise.

While I no longer work on this project [funding, politics, blah blah], I think it gave me some enormous insight into how bad some projects can be written, and steps one developer can take to make things a lot cleaner, readable and just flat out better with small, incremental steps over time.

Answer 1

Just because it has all those problems now doesn't mean it has to continue to have them. If you find yourself making a specific bug fix in the system that could benefit from, say, a new data layer, then create a new data layer. Just because the whole site doesn't use it doesn't mean you can't start using one. Refactor as you need to during your bug fixes. And make sure you understand exactly what the code is doing before you change it.

Problem with code duplication? Pull it out into a class or utility library, in a central location next time you have to fix a bug in the duplicated code.

And, as already mentioned by other responders - start writing tests now. It may be hard if the code is a coupled as it sounds, but you can probably start somewhere.

There is no good reason to rewrite working code. However, if you are already fixing a bug, there is no reason you can't rework that specific part of the code with a "better" design.