Re:Version 1 Sucks, But Ship It Anyway
by michael_dorfman on Friday December 04, 2009 @10:45AM
(#976502)
Atwood's a perfectionist? You couldn't tell it from the quality of his blog posts.
Version 1 sucks. Ship it anyway? Yeah, Cuil can tell you how well that worked out.
Clearly, the decision to ship is one that should be taken seriously, and the pros and cons of shipping need to be weighed. There's an upside to shipping early (feedback from users) but there are a lot of potential downsides as well.
Re:Version 1 Sucks, But Ship It Anyway
by _pius on Friday December 04, 2009 @12:22PM
(#976729)
Version 1 sucks. Ship it anyway? Yeah, Cuil can tell you how well that worked out.
Cuil didn't just ship; Cuil was launched Hollywood style with a tremendous amount of anticipation and buzz. If they had soft launched, their fail wouldn't have been nearly as epic.
Re:Version 1 Sucks, But Ship It Anyway
by daleharvey on Friday December 04, 2009 @12:35PM
(#976783)
I think as programmers we have a tendency to err on the side of taking shipping too seriously, this is a lesson I have been burnt by and probably wont get sick of hearing.
another important point I think that is part of the same, design your product in a way that allows you to ship early. forget about all the bells and whistles before you launch, think of the simplest possible thing that is useful.
this is a concious process and a bit different from just losing the fear of launching 'bad' stuff.
Re:Version 1 Sucks, But Ship It Anyway
by MikeMacMan on Friday December 04, 2009 @11:16AM
(#976560)
I understand Jeff's point, but this post tripped my false dichotomy alarm:
A. "spending three months fixing up this version in a sterile, isolated lab"
OR
B. "listening to feedback from real live, honest-to-god, dedicated users of your software."
You shouldn't need to 'ship' in order to get feedback from potential users. You should be engaged with them early-on, during the design and development of your product.
I would revise Jeff's argument to read: "Don't develop in a vacuum. Get feedback as early on as possible. If you need to ship something in order to get that feedback, then so be it, but that's risky. "
Re:Version 1 Sucks, But Ship It Anyway
by buckwilson on Friday December 04, 2009 @01:58PM
(#976955)
You just need to weigh the scope and reward of individual things. Some things are worth waiting for, others aren't. From a hype perspective a journalist can help you understand what your experience is missing for it to be considered a success to them.
For instance, before we launched a version of our software, we spent two months working on security mechanisms to make sure it couldn't be stolen or pirated or hacked. While security is important, it was a mistake for us to take it as seriously as we did, and we wound up wasting those resources in hindsight.
Version 1 sucks. Ship it anyway? Yeah, Cuil can tell you how well that worked out.
Clearly, the decision to ship is one that should be taken seriously, and the pros and cons of shipping need to be weighed. There's an upside to shipping early (feedback from users) but there are a lot of potential downsides as well.
But we all knew that already, didn't we?
Cuil didn't just ship; Cuil was launched Hollywood style with a tremendous amount of anticipation and buzz. If they had soft launched, their fail wouldn't have been nearly as epic.
http://www.google.com/trends?q=cuil
another important point I think that is part of the same, design your product in a way that allows you to ship early. forget about all the bells and whistles before you launch, think of the simplest possible thing that is useful.
this is a concious process and a bit different from just losing the fear of launching 'bad' stuff.
A. "spending three months fixing up this version in a sterile, isolated lab"
OR
B. "listening to feedback from real live, honest-to-god, dedicated users of your software."
You shouldn't need to 'ship' in order to get feedback from potential users. You should be engaged with them early-on, during the design and development of your product.
I would revise Jeff's argument to read: "Don't develop in a vacuum. Get feedback as early on as possible. If you need to ship something in order to get that feedback, then so be it, but that's risky. "
For instance, before we launched a version of our software, we spent two months working on security mechanisms to make sure it couldn't be stolen or pirated or hacked. While security is important, it was a mistake for us to take it as seriously as we did, and we wound up wasting those resources in hindsight.