The other day, Stephen sent me a link to an interesting article by Ben Kamens of the Kahn Academy entitled “Shipping Beats Perfection” Explained. Owing to a critically low level of caffeine in my system I initially struggled to understand why I should be interested in the delivery of the “Perfection” version of a software package called “Beats”.

When my English parsing ability rebooted, I dutifully scanned the article, admired the pictures of the dog, and blindly jumped to the hardwired conclusion built into any decent craftsperson of software.

Stop telling me that I’m gold-plating, polishing the round ball, sorting beach sand by size, running for political office, or doing any other pointless activity meant to diminish the nature of my efforts. I can tell you for a fact that we need to cleanup the object model in order to make it easy to modify in the future. If we don’t, all sorts of terrible things will happen like… like…

Normally at this point in my rant I find myself staring into the vacant eyes of a middle manager of some huge anonymous corporate structure. Said middle manager’s sole programming skill consists of realizing that nobody tests the code before it is shipped and if he marks all his tasks as “Done” he will get promoted before anyone realizes he hasn’t actually written any code. His idea of an “embarrassment test” is that the product ships on time, because if it does he will get promoted again. From his perspective in management, any problems in the code are an embarrassment to me, not to him. His carefully crafted “not my problem” attitude is not threatened in any way, so he is happy to maintain the status quo.

Of course my life isn’t like that any more. Long ago I moved away from such positions and my situation at Sharktank is relatively idyllic. On a second, coffee-fuelled review of the article, I didn’t get the impression that the Kahn Academy software team is run by such cluelessness either. And to be fair, I don’t think that their mantra is meant at all to refer to the tendency of programmers to add features that aren’t strictly necessary.

To me, “Shipping Beats Perfection” means that I prefer to give you a partial solution early rather than make you wait for a full solution. In fact, I prefer to give you many happiness-inducing incremental releases even if it results in a delay of the full release. By doing so I will release what you actually need, not what you thought you needed when we first started. I will constantly adjust what I’m doing as a result of the feedback I get from the release.

It is tempting to think that one should wait until a product is finished before one ships. After all, it is an embarrassment to ship with something that appears half finished. But when is a product finished? I think that software should borrow a saying from the growing of bonsai trees: it is only finished when it is dead. The rest of the time it is growing and changing. It needs shaping and forming during that time, but it would be foolish to say that we can’t display it until it is finished. Who wants to look at a dead bonsai tree?

The decision to ship is largely unrelated to the quality of source code that makes up the system. What we are interested in is the behaviour that is apparent to the user. In the majority of cases, if the software is providing benefit to the user and meets their expectations for a release, then it should be released. The more often you release, the better off you are.

There is a major caveat in this statement, though. We don’t want to get into a situation where releases get farther and farther apart. What we ideally want is a steady throughput of releases that incrementally add the behaviour that the customer wants. Creating a single release very quickly is a pointless exercise if it comes at the expense of all of the subsequent releases.

As software craftspeople, we must take care to spend an appropriate amount of time refining and perfecting our code so that we may generate the fastest possible long term throughput. We must be sensitive in our approach and create simple, yet elegant code so that we can modify it at will in response to unpredictable future requests.

Releasing early and releasing often is the reason that we must pay great attention to detail in our code. Shipping doesn’t beat perfection. Shipping enables perfection. It provides the heartbeat for any quality-minded team.