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.

A good perspective on Big Data for smaller companies

I follow the 37 Signals blog regularly. A great bunch of very smart people doing good work.

Noah at 37 Signals ate crow. He used to think Big Data was a bunch of bull for companies that don’t have the massive sets of data like Facebook, Google et al.

He changed his perspective on Big Data for small companies by testing platforms and databases for accessing large sets of data for these smaller companies. Here are a few quotes to summarize the post:

“The typical analytical workload with this data is a few gigabytes or tens of gigabytes – sometimes big enough to fit in RAM”

“None of this is an insurmountable problem, and it’s all pretty typical of “medium” data”

“The challenges of this medium amount of data are, however, enough that I occasionally wish for a better solution”

He then finds through his not-totally-scientific-testing that Impala from Cloudera provided good results.

“I’m thrilled to have been proven wrong about the utility of these technologies for businesses at sub-Facebook scale, and I’m more than happy to eat crow in this case.”

It’s a good quick read, check it out.