Victor Stone
March 29, 1999
You've moved into that phase of the product in which you are now sucking directly on the Folgers coffee bags. Your colleague likes to swish it around in his mouth with a gulp of microwaved milk and calls it a "latte." The press berates you for being late. Of course, "late" means missing the date that the marketing campaign was scheduled to launch—a date conjured by marketing and based on about the same reality plane as Clinton's truthfulness and Starr's objectivity.
Meanwhile your beta-testers are screaming because every mouse click forces a reboot on their production machines. When you ask them why they put your beta version on their production machines, they tell you it's because they couldn't wait for the final release to get the feature they requested. You don't have the heart to tell them their feature was cut during last week's product-scheduling meeting and isn't even in the internal daily builds anymore. All of the sudden your e-mail contact with them goes gravely dark as you figure they can wait until the next beta-release candidate to learn about this one.
When to pull the trigger and ship is actually much, much harder in commercial software than almost everyone, including an astoundingly large number of software professionals, fully appreciates.
My father was a software engineer, from the 1950s until just a few years ago, working on trajectory systems for spaceships, and eventually solving such problems as, "What is the formula that gets a Volkswagen from Florida to Jupiter?" In all that time he knew of one production bug (notwithstanding having me as a son). When I tell him that I've never heard of a major software release that didn't ship with scores of "known issues," he reacts as if I had thrown acid in his face: he takes off his glasses, shakes his head and rubs his eyes really, really hard. You see, when I was a kid, after a good day of work my dad would bring home pictures of other planets his programs helped make possible. Now, when I visit him, it's everything he can do not to beat me with his walker for my past involvement in ActiveX.
Modern professionals rely on the Software Readiness Continuum (SRC) to find the balance between when something is ready to ship and when to ship it anyway. Along the SRC you have three centers of gravity: raw, relevant, and ripe.
Most of us have experience with raw: software we don't really need, and a good thing, because it doesn't really work all that great anyway. The glory market days of raw software were from summer 1995 to summer 1996, a period widely known as the "browser wars." In a groping attempt to find some application for Internet connectivity, software companies thought it would be interesting to turn all computer users into beta testers and drop pre-release, beta-candidate software directly in the hands of all end users. The press, and some people in the industry, dubbed this "releasing software in Internet time." Cute, but ultimately a horrible drain on the companies, and a huge source of customer consternation—thanks to the number of backward incompatibilities these frequent beta releases created, and their overall lack of polish. And it wasn't even until the Christmas 1998 shopping season that there were any mature, widely usable, worthwhile consumer services on the Internet. Shipping raw software is fine when your audience is that special kind of gun-rack-in-the-cubicle crazy the makes for Quality Assurance engineers. Otherwise, grandma wants her Amazon Oprah Book Club bookmarks to "just work," okay?
On the other extreme, software can be considered ripe when its relevancy is in the rear-view mirror, and when the code base isn't worried about Social Security running out in 12 years. In fact, it wants to be retired so badly, it's hoping that Social Security runs out tomorrow, just to teach the raw-software whippersnappers a thing or two about living on the edge. The popular consensus is that the SRC actually mirrors the life cycle of a code base. According to this theory, the first stages of a code base, which yield raw releases, are driven by some over-bearded, stuck-in-adolescence "visionary" whom everybody respects though nobody remembers why. On the other hand, if your product version number is in double digits and it actually reflects the number of times you've shipped the same source base, you are pretty much guaranteed to be knocking on ripe's door. In fact, post-modern SRC scholars would claim this verges on a newly discovered level of the continuum even further than ripe: "rigor mortis" software. At this stage, the software is only being released at marketing's behest. They claim this is necessary so as not to "frighten" users into rethinking their choice of brand. Again, remember that we are beyond the point where relevance is an issue.
Which brings us to the middle ground, or "sweet spot," in the curve. History tells us there is a moment in the life cycle of a software code base that is the ideal time to ship it into general release and production. Does this mean it is completely free of known bugs? No, of course not. But it does mean that smart (and sometimes cruel) people have made the harsh calls on bugs that are timely and relevant to the vast majority of the software's primary audience.
Seasoned professionals, especially those beckoned by external forces, can make the mistake of thinking that the schedule of the product is the deliverable of the software. These same professionals tend to take the oft-used axiom, "Shipping is a feature," to mean, "Shipping is the only feature." But it should be obvious how easy it is to ship on time and still screw up the user-base—if the product is too unstable or missing the core relevancy in either direction. This is either because there simply aren't enough usage scenarios for the functionality to justify investment, or because its usefulness has been eclipsed—usually by a competitor who is hitting its stride in the sweet spot shipping relevant software.
Victor Stone is a Product Designer in the RAD Tools group at Microsoft. His most recent accomplishments include ducking under the crossfire of QA ("Don't even think about shipping this") and marketing ("We go tomorrow").