Version 1 Sucks, But Ship It Anyway(codinghorror.com)
codinghorror.com
Version 1 Sucks, But Ship It Anyway
http://www.codinghorror.com/blog/archives/001313.html
4 comments
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.
http://www.google.com/trends?q=cuil
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
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.
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.
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. "
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. "
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.
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?