The Software Development Edge: Getting It Out the Door
- If You Build It, They Will Come
- In the Beginning, There Was the Sandbox
- Why Should the Product Build Be Hard, Anyway?
- What About Iterative Development?
- Recap
This chapter is from the book
This chapter is from the book
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.
If You Build It, They Will Come2
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.