Rewriting web apps: pros and cons.

I’ve recently been thinking a lot about software rewriting, more specifically rewriting web sites and web apps. The reason for this is that I’m currently working on some code for a client that has transferred me onto their project after getting annoyed with the original developers failing to meet expectations. Without divulging too much, the site I’m working on is a shopping cart application and I was bought on just after launch because of many associated problems with the previous developers.

Now, in my opinion, the code isn’t very good. For starters the output isn’t XHTML compliant using CSS, the display logic is intertwined with the business logic, e.g. there is not template engine (which I’m not a great fan of) functions and patterns are repeated and it isn’t Object Oriented when it seems like an ideal candidate for OOP.

So the dilemma I’m having at the moment is “Should I rewrite from scratch or should I refactor?”

I’m going to let you in on a little secret: I’ve been here before, in a pretty much identical situation, and taking what I’ve learnt from this past experience I’m going to choose to refactor piece by piece. Last time, I chose to rewrite, and this is what happened.

Last time I was asked to make some important additions to an existing code base. However, this codebase was appalling, I could easily do better, I could really make it clean, efficient OO code, reducing the overhead on the server, making the codebase more extensible, producing superb XHTML which can easily be reskinned due to using a template engine produce the output. I just need to plan it out, think about it a bit, seeing how I could incorporate the important additions and rewrite the code and away we go!

Or so I thought.

What I completely forgot about was that I wasn’t re-writing the codebase in a vacuum: this was a live site, which (partly due to the original codebase and partly due to client requests) had to be updated/bug fixed/amended from time to time. Before long I had 2 codebases which both had to be amended to incorporate any new changes submitted by the client. This wasn’t feature creep, this was important changes and bug fixes which had to be done – the manufacture changing product specs, the credit card company being changed etc etc. Very soon I was bogged down by these changes. I spent more time re-planning the new code base to incorporate these changes, and amending the original code base the rewriting wasn’t getting anywhere. The months wore on and I had not released the new site, or made many of the original additions called for at the start of the project. Not surprisingly, the client dropped me. I had become so wrapped up in making the codebase “just utterly fantastic” I lost sight of the bigger picture: This was a real website with real customers and if the new features weren’t implemented the owner would lose business.

What stopped me seeing this was pride. I was far better than the other guys, I could write better, faster, more extendible code – but of course, this isn’t always true and better code isn’t always a better business decision.

I’ve been reading a lot into this at the moment, and I wish I had stumbled across these blogs before I started rewriting the project above.

Kevin Barnes “To rewrite or to not rewrite, that is the question” (ironically what I was going to call my article!)

Chad Fowler “The Big Rewrite”

And of course:

Joel Spolsky “Things You Should Never Do, Part 1”

Thinking about the situation I found myself in with the possibility to rewrite, I had these thoughts in mind:

  1. Is the project mission critical? If the rewrite takes longer than expected, will your client suffer? If they will, think carefully about rewriting
  2. Is the project fluid? I.E. will you have to make changes to the live site which will need to be included into the rewrite? If so be prepared to work on two code bases at the same time?
  3. Will you be able to devote a substantial amount of your time and brain power to the rewrite? This sort of works with point 2. If you either can’t support two code bases at the same time, or you won’t be able to spend the majority of the time on the rewrite then strongly consider not rewriting.
  4. Why are you doing the rewrite? Is it genuinely to improve the code, or is it because you simply think you can do it better? If the latter, or the latter is the majority reason for the rewrite, strongly reconsider the rewrite

All of these pointed me to rejecting my rewrite plan. So, this time, my plan will be different. This time I’m not going to ditch the old code base (even though I really want to). This time I’m going to do it bit by bit. Improving each area that I have to fix a bug for, or make an addition. I’m going to refactor slowly, but carefully.

And most importantly I’ll be keeping in mind the real reason I’m doing this: this site is my client’s lively hood, not my plaything.

Note: This post has been copied from the old website, originally posted on 2007-11-13. See this entry for more details