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.

  • We’re refactoring some code at the moment, in parallel to implementing revised parts of the site as we go. New build delivery time frequency slows a bit, but we can still add and change bits if urgent – much preferred to ‘closed for refurbishment’. Features + Cleanup + bigger load handling – do hate the “chuck money at server bottleneck” approach.

  • We’re refactoring some code at the moment, in parallel to implementing revised parts of the site as we go. New build delivery time frequency slows a bit, but we can still add and change bits if urgent – much preferred to ‘closed for refurbishment’. Features + Cleanup + bigger load handling – do hate the “chuck money at server bottleneck” approach.

  • All pretty sound points – especially the one about annoying your customers. However, I think the exception is well spelled-out by Brook: “software is like waffles: throw the first one away”… so with that in mind I’m applying the principles above to any software version other than the first one.

  • All pretty sound points – especially the one about annoying your customers. However, I think the exception is well spelled-out by Brook: “software is like waffles: throw the first one away”… so with that in mind I’m applying the principles above to any software version other than the first one.

  • Nic: Thanks for the reference to the OnStartups article.

    Jof: I am a fan of Brooks myself. However, I think the “throw the first one away” as a general rule is risky — particularly for startups.

    Though ideally, you’d have the time to start over and throw the first one away, we don’t live in an ideal world. Even though in the long-term, throwing the first one away might be a good idea, you have to *survive* the short-term for the long-term to ever matter. For big companies where the long-term is a given, this might be ok. For startups, when resources are severely limited, it’s not an easy decision.

  • Nic: Thanks for the reference to the OnStartups article.

    Jof: I am a fan of Brooks myself. However, I think the “throw the first one away” as a general rule is risky — particularly for startups.

    Though ideally, you’d have the time to start over and throw the first one away, we don’t live in an ideal world. Even though in the long-term, throwing the first one away might be a good idea, you have to *survive* the short-term for the long-term to ever matter. For big companies where the long-term is a given, this might be ok. For startups, when resources are severely limited, it’s not an easy decision.

  • Agreed, but it depends what you mean by the “first one”. For example, what’s the harm in throwing away a prototype that only took 2 weeks to make? The advantage (and it’s a massive advantage) to this approach is that it means you can get something “out there” and learn what users really want – which is often completely different to what even experienced startup founders might expect. What’s the point of keeping the first one if no one likes it? You’d be flogging a dead horse.

    I’d go further to say that this is one of the advantages of having a startup, especially in this space where costs can be extremely low; the option to throw something out there and completely rebuild after a couple of weeks/months, if it’s not getting traction, is a great thing. And it needs to be stressed that for many readers of Nic’s blog (including me) the concept of a startup is a few people bootstrapping some ideas in a garage, so I would question what “risk” actually means in reality for these people.

    However, I’m straying off the point of the original post. I’d definitely agree with anyone who says that rebuilding a live web app (with lots of users and/or lots of revenue) from scratch is a difficult and often – but not always – wrong thing to do. But even then, if your re-build enables you to jump tracks onto a better revenue stream and faster growth then it needn’t be a case of throwing the baby out with the bathwater.

  • Agreed, but it depends what you mean by the “first one”. For example, what’s the harm in throwing away a prototype that only took 2 weeks to make? The advantage (and it’s a massive advantage) to this approach is that it means you can get something “out there” and learn what users really want – which is often completely different to what even experienced startup founders might expect. What’s the point of keeping the first one if no one likes it? You’d be flogging a dead horse.

    I’d go further to say that this is one of the advantages of having a startup, especially in this space where costs can be extremely low; the option to throw something out there and completely rebuild after a couple of weeks/months, if it’s not getting traction, is a great thing. And it needs to be stressed that for many readers of Nic’s blog (including me) the concept of a startup is a few people bootstrapping some ideas in a garage, so I would question what “risk” actually means in reality for these people.

    However, I’m straying off the point of the original post. I’d definitely agree with anyone who says that rebuilding a live web app (with lots of users and/or lots of revenue) from scratch is a difficult and often – but not always – wrong thing to do. But even then, if your re-build enables you to jump tracks onto a better revenue stream and faster growth then it needn’t be a case of throwing the baby out with the bathwater.

  • Mat

    We’re going through some of these issues at ProofHQ now.

    We threw away the first couple of prototypes, but from the point we created a fully working application we have only refactored. New API, new permissions engine, etc. The temptation is to go for the big rebuild, and that pressure is ground-up from the development team.

  • Mat

    We’re going through some of these issues at ProofHQ now.

    We threw away the first couple of prototypes, but from the point we created a fully working application we have only refactored. New API, new permissions engine, etc. The temptation is to go for the big rebuild, and that pressure is ground-up from the development team.