Launch with bugs

How many (and what type) bugs you can afford to let slide really depends on your users' needs:<p>As a biomedical technology, we have to demonstrate the scientific accuracy of the product we ship. We also have to be aware of the consequences of bugs to our users. While Facebook users may not mind a slightly finicky widget, laboratory technicians are much more sensitive.<p>I'm all for rapid iteration and product development, but I think it's important to ship things that are context-appropriate. I also feel that there's substantial, if intangible, value to being proud of what you ship.<p>I worry that a culture of shipping somewhat-broken things may end up doing us harm.

Sigh, more "everybody do this" writing. I guess the internet loves binaries and absolutely hates subtlety, but does shit like this really need to keep being brought up when the really appropriate answer is just do what your audience will put up with?

I think whether or not it's a good idea to launch has to do with what those bugs are. The number of bugs is pretty much irrelevant.

Wasn't surprised to see this was a Rails developer.

More appropriate title should have been "launch with lots of bugs and it is still ok" in the context of this post. "Launch with bugs" will have meaning when you could actually launch without bugs. Of course, any software will have bugs when launched or even if well matured.

Works well when you control the patch/upgrade deployment. Not so good when you don't. And not so good when it stops your customer doing what they want to do.

This is too general ... "Launch with bugs that are unimportant to the main features of your product" might be better.

It's as if the author believes that Basecamp was released with +100 known bugs.

Nobody's perfect, you cannot choose, start with, or without bugs...