Comments on: Why you should almost never re-write your software

By: Mat

Mat — Thu, 10 Apr 2008 17:27:44 +0000

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.

By: Jof Arnold

Jof Arnold — Wed, 09 Apr 2008 08:10:34 +0000

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.

By: Dharmesh Shah

Dharmesh Shah — Tue, 08 Apr 2008 20:16:12 +0000

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.

By: Jof Arnold

Jof Arnold — Tue, 08 Apr 2008 12:41:36 +0000

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.

By: paulpod

paulpod — Tue, 08 Apr 2008 12:06:06 +0000

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.