DISQUS

DISQUS Hello! The Equity Kicker is using DISQUS, a powerful comment system, to manage its comments. Learn more.

Community Page

The Equity Kicker

Nic Brisbourne’s view from London on venture capital and exploiting change in technology and media
Jump to original thread »
Author

Why you should almost never re-write your software

Started by brisbourne · 6 months ago

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 rewr ... Continue reading »

5 comments

  • paulpod

    1 year ago

    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.
    reply
  • Jof Arnold

    1 year ago

    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.
    reply
  • Dharmesh Shah

    1 year ago

    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.
    reply
  • Jof Arnold

    1 year ago

    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.
    reply
  • Mat

    1 year ago

    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.
    reply

Add New Comment

Returning? Login