Chapter8.Getting It Out the Door

Chapter 8. Getting It Out the Door

I have on occasion claimed that I can build the perfect product. Just don't ask me to ever ship it.

As soon as you require that I ship a product on a given date, I can guarantee you that the product will be imperfect. It will disappoint someone along some dimension. It will lack some feature, exhibit some annoying minor bug, or will lack some piece of documentation. No doubt there will be rough edges in its user interface. If only we had more time…

This is not a phenomenon unique to software products. A shipped product is always a compromise between the product we would ideally like to shipthe one that approaches perfectionand the one we really need to ship because we must begin generating revenue. And sometimes, believe it or not, the product we ship is good enough, even though it represents a compromise. The test is whether or not it serves the greatest good for the greatest number.

Consider an update release of an existing product, one that will add some new features and fix many annoying defects resulting from the previous compromised release. You can work on this update as long as you like; the longer you take, the more features you can add and the more bugs you can fix. But here's another way to look at it: The longer you wait to ship that update release, the longer your existing customers will have to live with the bugs in the version they are currently using. So the tradeoff becomes this: Is it better to ship 50 bug fixes today, or 55 in another two weeks? If you have thousands of customers who are suffering with Bug #29 on the list every day, I think I can make a pretty good argument for shipping yesterday.

Once you realize that shipping the product is not only part of your job but in fact the critical stepBob Bond^[1] would call it "running it through the tape"you need to consider exactly what is required to go from some assemblage of working bits to a package that you can put on the loading dock or, alternatively, some set of files that you can stage on your download server. You need to consider testing, installation, documentation, preparing the support organization, and many, many other details. Like the death from a thousand cuts, getting this all right can be extremely painful the first hundred or so times you do it. It is one of those exercises that require method and persistence, and extremely meticulous follow-up.

^[1] Bob Bond ran sales and marketing at Rational for many years. He was a very positive mentor for me.

The purpose of this chapter is not to bludgeon you to death with the obvious. What I focus on in this chapter is a small subset of the problem: How do we "close out" development of the software so that we can ship the product? When we are on "final approach" to shipping the product, what changes? The answer is this: If you have been doing it right, the change is imperceptible. If you have neglected thinking about this problem all along, then you will suffer large, severe, and disruptive change at the end, and your ability to ship will be endangered.