DISQUS

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.

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.

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.

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.

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.