Why you should almost never re-write your software

By April 8, 2008Entrepreneurs

Following the closure of Blogfriends I am experimenting with new feedreaders and on the strong recommendation of Jason Ball I have been trying out Feeds2. I am struggling with the interface a little, but today came across an old post from OnStartups entitled Why you should (almost) never rewrite your software.

The advice echoes my own experience. Too many of the startups I have seen embark on a software re-write never emerge properly from the experience. It takes too long and the market moves forward whilst you stand still. The five reasons OnStartups gives are:

1. It Will Take Longer Than You Think: Despite what you may think, rewriting your software will probably take almost as long the second time as it did the first time. Sure, you have more information now on what you need to build, but this information is already dated.

2. Markets Change: Chances are, your market is not going to hold steady and wait for you to get done with your rewrite. While you’re busily rewriting the same software again, things are changing. Competitors are coming in. Demands are different.

2. Markets Change: Chances are, your market is not going to hold steady and wait for you to get done with your rewrite. While you’re busily rewriting the same software again, things are changing. Competitors are coming in. Demands are different.

3. Existing Customers Become Frustrated: Existing customers are going to want fixes and features to the old stuff (the stuff you’re getting ready to throw out). The best you’re going to be able to do is hobble along on some old version of your software, make small fixes, make all sorts of promises to customers about why the next version is going to solve all their problems. You’re going to sleep even less hours (if that were possible). There just won’t be resources to maintain your existing software and work on the rewrite. Even if there were, you’re probably then going to have to deal with two different versions of the codebase which creates a whole other set of problems.

4. Refactoring Can Cleanup The Code: If the code is indeed a mess, you don’t necessarily have to rewrite everything all at once to make it better. Refactoring is a great way to do this, a step at a time. (Refactoring is changing the internal structure of the code without modifying its external behavior). The upside to this is that all along the way, you still have working software that you can change.

5. You Don’t Control The Rewrite, It Controls You: One of the great things about refactoring is that you get to pick how much of your time you allocate to cleaning up existing stuff and how much you allocate to responding to new market demands. (And please spare me the excuses that you don’t have the discipline to refactor, you’re better than that). Should some massive change happen in your market (like a worthy new competitor), if you are refactoring a piece at a time, you have a fighting chance of responding. If you’re in the middle of a rewrite, you’re probably toast.

Refactoring worked well for us at buy.at and is a much better way to go.