Rewrite or not?

We face this question, “Rewrite or not?” with customers every year.

“We have a custom software application written by [ABC company or programmer] in [XYZ technology]. It works but it has problems. Should we keep it alive and continue modifying it? Or should we start from scratch again and rewrite it?”

That is a very good question. This question of keep alive or rewrite the software has been addressed by others in our software industry. This specific article references the recent rewrite from scratch of the well known project management tool Basecamp by 37Signals, and a timeless article by Joel Spolsky on the same topic but with the opposite view.

The summary of the two opposing points of view are:

  • Rewriting is good because the old product was well done but was written for a different time, with a different frame of mind, and with old technology. Everyone will be better off with better application.
  • Rewriting is bad because “You are wasting an outlandish amount of money writing code that already exists”…the loads of code debt or bad code can be fixed, a rewrite isn’t necessary.

These are both solid, well supported lines of argument. But I think they are addressing different situations. Jason Fried of 37Signals doesn’t talk about Basecamp being a bad application with bad code, just that it was great, but can be better. And let’s face it, if you follow the software company 37Signals you know they’re not hurting for money and can afford to do a complete rewrite.

Joel Spolsky addresses the other type of software application, the ones with problems, bad code, slow performance, etc for the large, widely distributed applications. He says all of those things can be fixed and the cost to the fixing is much, much lower than the rewrite. He’s write…err, I mean, he’s right.

What I like is the clarification by the blog post author, Garry Robinson, that the software application should be rewritten if either the database design really poor, or the code is really poor because the developer(s) didn’t know what he/she was doing, or both.

Garry is essentially saying it’s a matter of severity; if it’s really bad, rewrite. I agree. Issues can be fixed if the problems aren’t endemic throughout the code and database. But if they are, rewrite.

In fact we are facing that exact situation with a customer’s application. An application was built by an internal person years ago with Microsft Access and SQL Server. On their own those are fine tools to use for this situation, and a great custom software application can be written with them. But the way it was written was…well, it was not good (an understatement). The application is really hard to support, especially in some specific feature areas.

We are now working with the customer to do a complete rewrite. It will give them a solid application that won’t have the frequent issues it had before. The customer will also get new features and capabilities they couldn’t dream of with the old application.