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.
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.
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.
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. "
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.
[+] [-] michael_dorfman|16 years ago|reply
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?
[+] [-] _pius|16 years ago|reply
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
[+] [-] daleharvey|16 years ago|reply
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.
[+] [-] MikeMacMan|16 years ago|reply
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. "
[+] [-] dan_sim|16 years ago|reply
[+] [-] nathanb|16 years ago|reply
[+] [-] buckwilson|16 years ago|reply
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.