Joel Spolsky: “Listen, I know that everybody is saying that the cool thing to do these days is Ship Early and Often, but when you ship half-baked ajax calendars that don’t do much and then get Scoble to go nuts about how great they are, well, you’re going to have a lot of people like me checking it out and realizing that, for example, no thought whatsoever has gone into printing, which is fine, it’s a 1.0 release, but you know what? I’m not going to look at 30 Boxes again — I’ve spent enough time evaluating it. G’bye. I’ve talked about this before — it’s the Marimba phenomenon — when you get premature publicity, lots of people check out your thing, and it’s not done yet, so now most of the people that tried your thing think it’s lame, and now you have two problems: your thing is lame and everybody knows it.”

“Release early, release often” is a strategy that works because it allows for incremental improvement—you don’t have these “big bang” releases every few years where you try to anticipate what your users will want, because your users are telling you what they want every step of the way while the thing is coming together. That said, Joel makes some very good points, and companies following the “release early, release often” formula would do well to consider them. In short, for “release early, release often” not to backfire, its proponents need to do a better job differentiating between the users that want to actively participate in the development of a new product and the users that are simply looking to solve a problem, because that latter group is ultimately going to be disappointed if the thing isn’t fully baked.