The blogosphere has gone a bit crazy the last few days with posts responding to Joel Spolsky’s latest article about "The Duct Tape Programmer". Bloggers everywhere are tossing their two cents in and saying what parts of Joel's post was good and what wasn't good. Once noticeable trend is that many have jumped on the "just ship it" bandwagon.

There’s a quote mentioned by Jamie Zawinski in the article:

“Yeah,” he says, “At the end of the day, ship the f---ing thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.”

I don't know Jamie and I imagine the context that the comment was made in was based around some pre-existing level of candor with the person he was speaking. We really don’t know what “…ship the f---ing thing” means in the context of that conversation and what level of quality is expected in that scenario. I would agree with Joel/Jamie that shipping products is important and that often developers (myself included) run the risk of becoming too entrenched in a design or beauty and all too easily miss the point of developing software...which is to ship a product that adds value.  However...”shipping” is only part of the picture. As someone responsible for the value of the product my team ships, I’m keenly aware of what affects shipping early can do (both the positive and negative).

I'm reading a lot where people say "just ship it" but I've been part of teams where shipping too soon costs more money in the long run (and sometimes not even “the long run” but a few days/weeks down the road). These pro “ship it” bloggers surely must be talking about non-critical business systems when we say "just ship it"; would you want to ride on a plane where the flight control systems were sent out with bugs? Even a measly 1% failure rate of airplane system is unacceptable and is enormously expensive both in dollars and reputation for an airline.

The point is that shipping is the point but not the whole point, it's only one aspect of a well delivered software product. Shipping software with value is the point.  Ship too soon with bugs and the value gained by shipping is potentially lost.  Conversely shipping late provides no value at all.  Neither lobbing a piece of crap over the wall at your customers early, nor refactoring your code till it shines is the point, neither should be considered a success. There’s a sweet spot that you need to find.  Keep in close contact with your customer, if you pay attention they’ll let you know when you’ve crossed into either extreme.