Alex Rivera | Logout

When to rewrite a code base from scratch

Asked 2009-06-30T15:37:46.050
70

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

architecture tdd testing
Edit
Report

2 Answers

12

I have had such an application, and rewrite was very rewarding. However, you should try to aviod the "improvement" trap.

When you rewrite everything, it is very tempting to add new features and fix some long-standing issues you didn't have the guts to touch. This can lead to feature creep and also extend the time needed for rewrite enormously.

Make sure you decide what exactly will be changed and what will only be rewritten - in advance.

answered 2009-06-30T15:42:02.797
3

My answer is: rewrite from scratch as often as possible.

I've spent most of my career inheriting steaming piles of dung we politely called "programs", written by young, inexperienced programmers who were considered "rock stars" by the managers. These things are generally unfixable, and you end up spending 10 times as much effort keeping them limping along as you would have spent just rewriting them from the ground up.

But I've also benefited tremendously by rewriting my own work periodically. Every rewrite is a chance to do things differently and potentially better, and you should be able to reuse at least some parts of the older version.

That being said, not all rewrites are a good idea. Windows Vista, for example.

answered 2009-07-09T13:29:11.300

Your Answer