Launch with bugs (opens in new tab)

(scottmeade.wordpress.com)

16 pointsscott_meade13y ago16 comments

16 comments

16 comments · 9 top-level

bproctor13y ago· 4 in thread

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.

scott_meadeOP13y ago

Good point. So, more accurately, don't let the fear that their just might be undiscovered small bugs prevent you from launching.

jmathai13y ago

Not just undiscovered bugs but non-critical bugs. If it doesn't cause data corruption then I say launch and fix it later.

Fixing that bug is probably less valuable than getting the feature into the hands of users.

Also, don't stress about "losing" users. There are plenty of users and you'll be surprised how forgiving your users will be if you're open about bugs and fixing them.

swensel13y ago

Agreed. It's better to just get the product out there.

joshaidan13y ago

Yeah, you probably want to avoid privacy related bugs, or bugs that allow people to steal credit card numbers or passwords.

spartango13y ago· 2 in thread

How many (and what type) bugs you can afford to let slide really depends on your users' needs:

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.

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.

I worry that a culture of shipping somewhat-broken things may end up doing us harm.

asynchronous1313y ago

That was my first thought as well. I make unmanned helicopters -- it's cool to ship a half-ton flying machine with software bugs, right?

But the article did at least make it clear that the advice was targeted at smaller SaaS providers. Depending on the users needs, that might be okay.

lukeholder13y ago

The concept of shipping asap does not have to mean a complete rollout or the entire biomedical industry, but shipping to a production system that a certain group of users USE for actual work.

Shipping® also encourages a single source of truth for the development team to work from. The master branch is really just another branch when a project does not push that master immediately to production.

damian200013y ago· 1 in thread

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

bradhe13y ago

Bingo. I've seen (and shipped...) a lot of shit software under the guise of "bugs are OK--done is better than perfect...right? ...guys?"

te_chris13y ago

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?

fmblwntr13y ago

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

codegeek13y ago

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.

chris_wot13y ago

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.

wmt13y ago

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

jmurda13y ago

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

j / k navigate · click thread line to collapse