Is rewriting the code “startup suicide”?

Came across this article by Steve Blank – “Startup Suicide – Rewriting the Code“. This can be summed up as:

  • Under the pressures of growth, some startups allow their code base to get messy.
  • This mess – and the pressure to keep it working – results, over time, in a slower delivery of features.
  • This leads to a failure to adapt, which is seen as an existential threat to the future of the business,
  • The business decides that a rewrite of the product is the way to go.
  • This leads to death.

I don’t dispute the main premise of the article, but I do dispute the title. The answer is to rewrite the product. The question is: how do you do that?

Let’s put the obvious on the table: the company is already doomed unless something changes. The failure to adapt will see the company collapse eventually – and they recognise it. Preserving the status quo is not an option.

The riskiest thing is to do nothing

Ergo, taking a risky decision can’t be considered suicide (it may be euthanasia). The old code has to go away – or, at least, not be worked on anymore (eventually). Still, there are smart decisions and dumb decisions.

  • Stopping all work on the current version to write the new one? Dumb. You bring forward the fate you’re worried about (not being able to adapt and deliver change). Unless you can deliver the new version in a very short time period, don’t go here.
  • Continuing to add features to the existing version while trying to get the new one up? Also dumb. First, you slow down your rate of delivery on your old version. Your new version is going to take longer to deliver. You probably have do changes in both – double the work, for no more benefit. And, of course, you create a two-teir culture – nobody wants to work on the old platform.

The smart option (well, one smart option) is to work out how to build the new version and integrate with the old version. All new features get built in the new version. When you need to change an existing feature, you rewrite just that feature in the new version (with the change you want), and change the old version just enough to integrate it with the new one. And deliver the new version – integrated with the old – on short time cycles.

This way, you move the bulk of your development into the new version – a little at the start, and ramping up as it gets stable. You deliver the new version integrated with the old – from the user’s point of view, it’s one product. You start to get immediate payoff from the investment, and you reap the benefits in the most valuable area: the places things are changing right now. Over time, this becomes the places things change the most frequently. Sure, you’ve still got some of the crufty legacy system lying around, but if it’s not being worked on, does that matter?

Exactly how you achieve the integration will vary, depending on what the product is and the technology choices you have. My personal preference would be to move towards a modular set of services – the old application would be a client to the service, and eventually (as it gets thinner and thinner), you can put a new client in its place. The new services don’t have to do everything you need immediately – they just need to do enough. This works particularly well if the challenge is how do you get onto multiple platforms (where you need multiple clients by definition)

You do need to be careful with this approach. The biggest thing to watch out for is “don’t repeat your mistakes”. The old system started clean and got crufty for a reason – if you don’t correct that, you’ll make the new system crufty as well. You can’t just assume that it will be clean and stay clean – the natural tendency of a changing code base is to rot over time, and it takes engineering discipline – especially in the face of deadline pressures – to prevent that.

The last piece of advice here is to not focus too much on what the old system did then as you deliver the new version. Instead, focus on what you want the new system to deliver now.

“I skate to where the puck is going to be, not where it has been” – Wayne Gretsky


Author: Robert Watkins

My name is Robert Watkins. I am a software developer and have been for over 18 years now. I currently work for people, but my opinions here are in no way endorsed by them (which is cool; their opinions aren’t endorsed by me either). My main professional interests are in Java development, using Agile methods, with a historical focus on building web based applications. I’m also a Mac-fan and love my iPhone, which I’m currently learning how to code for. I live and work in Brisbane, Australia, but I grew up in the Northern Territory, and still find Brisbane too cold (after 16 years here). I’m married, with two children and one cat. My politics are socialist in tendency, my religious affiliation is atheist (aka “none of the above”), my attitude is condescending and my moral standing is lying down.

4 thoughts on “Is rewriting the code “startup suicide”?”

  1. I really think that your last paragraph is very important:

    “The old system started clean and got crufty for a reason – if you don’t correct that, you’ll make the new system crufty as well. You can’t just assume that it will be clean and stay clean – the natural tendency of a changing code base is to rot over time, and it takes engineering discipline – especially in the face of deadline pressures – to prevent that.”

    If you don’t change the environment which caused the original mess, the “new hotness” is going to end up in the same state — after all, it has just the same pressures on it as the original system.

  2. An Interview with Joel Spolsky:

    SoftwareMarketSolution: Joel, what, in your opinion, is the single greatest development sin a software company can commit?

    Joel Spolsky: Deciding to completely rewrite your product from scratch, on the theory that all your code is messy and bug-prone and is bloated and needs to be completely rethought and rebuilt from ground zero.

    SMS: Uh, what’s wrong with that?

    JS: Because it’s almost never true. It’s not like code rusts if it’s not used. The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it.

    SMS: Well, why do programmers constantly go charging into management’s offices claiming the existing code base is junk and has to be replaced?

    JS :My theory is that this happens because it’s harder to read code than to write it. A programmer will whine about a function that he thinks is messy. It’s supposed to be a simple function to display a window or something, but for some reason it takes up two pages and has all these ugly little hairs and stuff on it and nobody knows why. OK. I’ll tell you why. Those are bug fixes. One of them fixes that bug that Jill had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes a bug that occurs in low-memory conditions. Another one fixes some bug that occurred when the file is on a floppy disk and the user yanks out the diskette in the middle. That LoadLibrary call is sure ugly but it makes the code work on old versions of Windows 95. When you throw that function away and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s