Fast development, or stable results, which is more important for public web site/services?

Question

This is really just me soliciting a number of opinions and as a relative newbie to this site, I hope I was correct in marking this post as a community Wiki. If I was mistaken, can someone please correct my mistake.

Anyways, here is the scenario. I am developing a web application and a number of services in support of that application. I am having a nasty time of deciding how to do things. What I am working on is very feature oriented and to be honest, I can add new shiny features at a pretty good rate. Shiny new features obviously can be quite effective at attracting new users to my service.

At the same time, for every feature I add, I increase my debugging, usability and other even more mundane tasks ( localization, graphics/UI development, documentation, etc... ).

It really is a tightrope walk. I want enough functionality that people will use my services and to differentiate between possible competitors. I also want to generate a great deal of WOW factor, to create more person to person buzz, so I can grow organically. At the same time, I do not want to ship a flawed project, where people would run in to bugs/glitches/flaws and then never return, or worse, create a negative buzz.

So, in a nutshell, that is my question. What is more important on a web based site/service... volume and speed of releasing features, or stability and polish?

I would love to choose both, but resources are definitely finite! As it stands, I have tried my best to balance both and have gone way past my (self determined ) deadlines as a result.

Answer 1

Fast, Reliable, Cheap. Pick two.

Answer 2

Although the use of the phrase "in a web2.0 world" made me groan, you might appreciate the wisdom contained in Getting Real, a book written by 37signals, the folks behind Basecamp, Campfire etc.

Answer 3

Without avoiding the question, I would say both... This is exactly what Agile Development Methodologies are made for. Create Unit Tests/pair programming for stability, and implement a frequent build cycle.

Answer 4

Most web2.0 companies tend to have a product that they think could work because it's different but there's an element where getting to market is (or seems) as important as getting something feature complete.

Agility is key to lots of them too. Getting something out there and getting feedback on that can result in a much better product that something fully conceived and rendered behind closed doors.

I don't think you have to sacrifice any stability, having billions of bugs, but a perpetual beta state means you're willing to build on and improve what you've done and users should expect frequent changes.

Answer 5

The question boils down to which is greater: The benefit from new features or the harm caused by bugs left unfixed, i.e. how good are the new features and how bad are the bugs?

While I don't know how to quantify that, I think I'd review existing bugs and if there is a particularly major one or a large enough number to merit its own project then I'd do that before going back to mostly working on features since it is the new things that may get people's attention if your business is at that state.