I've spent the last few days diving. Scuba and photography fight it out for third place in my interests (after family and work). To understand the hazards involved I studied scuba accident reports, and they mirror things I'd read in aviation: the change from "normal" to "disaster" is hardly ever instant – instead the cause is a chain of events and/or actions. Breaking that chain is key to disaster avoidance - and one of the major lessons in my scuba training was to keep thinking "What are my options here?"
The Windows Server virtualization team have announced their public beta will coincide with the release of Windows Server longhorn and that some features have been deferred. Forecasting is an inexact business – especially around software development, in software as in scuba when you realise that things aren't going plan you have to ask yourself is "What are my options here ?" and balance time, quality and features. You have 3 basic options
Option 1. Denial. Not all signs of trouble are the beginning of a disastrous chain: you could ask "How might this develop – and what are my options if it goes the wrong way?" – Or you could insist that everything will be alright. In scuba you may have less air left than you planned but continue with something which needs a reserve – like going into a wreck. This could be a link is a fatal chain of events. In Software even when you need to test more cases than you first thought and development is taking longer than you expected, you can insist that if everyone works hard then you'll ship on time and won't have any noticeable quality problems. This produces (a) Demoralization. The developers know the product is destined to be a wreck and know that management is in denial. Eventually word will get out- which leads to... (b) Distrust. No-one will believe your next project is on track.
Option 2. Delay. Do the things you meant to but later. In Scuba, if you're exhausted after a dive then make the next one later than planned, if you haven't the air to accomplish the things you wanted, do them on another dive. In software you can push back the release date of the whole product, or at least some of its features.
Option 3. Ditch. Things are so far gone you have to abandon the dive / project (or one of their features). This is the option everyone wants to avoid, if the alternative is "making your next dive to 6 feet in a wooden wetsuit", or ruining customer relationships with an irredeemable product that's what you have to do.
A re-plan is pointless unless you are confident of success: both in Scuba and Software. Machiavelli isn't as widely read in Redmond as you might think – but he said when you have do something unpleasant, do it once and decisively so you don't alienate people by doing it again and again and again. Program managers need to follow that advice. If you push back feature X, and then feature Y and feature Z, that's worse than pushing all 3 back together – even if you realize on release that X could have stayed
Having gone through the "Redmond, we have a problem" moment and decided "Denial is not an option" the WSv team faced the choice: keep the features or keep the schedule. They chose the latter, which meant deciding which features get delayed. I've had 3 or 4 days to think about this and I think they got it right. Features about how individual VMs behave stay. Deferred features affect how an environment of many VMs is managed. There are two separate questions for customers to address. "Does this product run our workloads well?" and "How good a dynamic environment can we build to run our workloads". People can answer the first, but must wait to answer the second. How long might the wait be? In a perfect world we'd see these features in "Virtualization SP1", which would go into beta when Virtualization itself releases, and ship 3 to 6 months later. But predicting if the dates will line up to allow that would be to layer guesstimate on guestimate.
There are some customers who could barely wait for WSv before this announcement. This bit is painful for Microsoft people. Customers should buy the product which best meets their needs – and overall I'm happy with how often that is the Microsoft product. One of my pet sound-bites is "We and our customers want the same thing: Both of us want them to have an excellent experience of our technology." If they can't get that - if we don't meet their needs on features, timescale or anything else - they should buy another product. Someone who ends up as a happy VMware customer does us less harm than ending as an unhappy Microsoft one.