We all have that perfect product that we just know we could produce if only we were given forever to build it. Unfortunately, in the real world, there are pesky things called deadlines that interfere with our dreams. This chapter will help you balance that perfect dream with the reality of getting your product out the door and producing revenue.

This chapter is from the book

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 ship—the
one that approaches perfection—and 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 step—Bob Bond1 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.

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.

In the world of software products, there are successes and failures,
determined by the free market system. We must, of course, add to the list of
failures those projects whose products never see the light of day—the ones
that are worked on for various lengths of time but never ship. As obvious as it
sounds, you cannot be successful unless you meet the precursor of shipping your
product.

As you cannot ship what you cannot build, actually putting together the
pieces becomes critical. Intrinsic in this is the concept of a
repeatable build process. You will build the product over and over
again, until one of your candidate releases passes muster and you let
it out the door. I now confront the issues involved in creating such a
repeatable build process for your product.