News

The Danger of Betting on the Future

• By Mike Gunderloy
• March 11, 2004

For developers, the big news out of Microsoft this week starts with a pair of official product names. Visual Studio .NET "Whidbey" is now Visual Studio 2005, and SQL Server "Yukon" has become SQL Server 2005. With those names, Microsoft makes explicit something that beta-watchers have been guessing for a while: the schedule for the next round of developer products has slipped again. While Microsoft is now talking about ship dates in the first half of 2005, they could ship any time up to next December and still not look too silly with those names attached.

The SQL Server slip is especially troubling to those of us who've been expecting a new version of SQL Server since the original planned release date of some time in 2003. Worse, we've now got folks in the SQL Server group talking about the possibility of feature cuts after beta 2, meaning that five years of development might not be enough to deliver everything that they've promised us.

Of course, plans for SQL Server had undoubtedly changed in that time. Right now integration with the .NET Common Language Runtime (CLR) is front-and-center as an important SQL Server feature. That means that SQL Server has to synchronize with the next .NET release, and therefore with the next Visual Studio release. And they both have to run on Windows Longhorn, which means that the schedules of all three products are thoroughly entangled. The result is an incredibly difficult logistics problem for Microsoft, and I have no doubt that many talented people are working many hours to sort it all out.

The impact of the slip is going to be worst on those developers who have already started using the Whidbey and Yukon bits that have been circulating since last year's Professional Developers Conference. Even though Microsoft made it clear that these were alpha-quality bits, I know some folks whose attitude is "I can start building with these now, and the release versions will be along in time for me to roll out the product." Imagine going back to your boss this week and admitting that you guessed wrong, and that WhizBang 4.0 will have to wait until early 2005 to release because you gambled and used new Yukon features in your core database? That's what some of these people are having to do now.

It's our own darned fault, of course. Some time in the last 15 years, beta programs have changed. When I first started participating in Microsoft betas, they were handed out to very small groups of external testers. We took confidentiality seriously; people wouldn't even tell you which products they were beta-testing. Serious feedback to the product groups happened as a matter of course. And no one ever mistook a beta release for something that could actually be used in production.

Now things are different, in large part because too many people see being on betas as a status symbol. Microsoft hands out beta and even alpha code like it was throwing raw meat to hungry puppies. And on our side of the fence, we eagerly snap up these DVDs, anxious for the bragging rights that they confer. People who have no earthly need to be porting their code to Longhorn are installing virtual machines and trying to learn XAML, just so they can look their peers in the eye. It's a crazy world.

If you learn one thing from the SQL and VS slip, learn this: don't bet your project on beta code and Microsoft release schedules. Yes, it's wise to know what's coming down the pike, and to have some plans for working with it. But it's just plain silly to link your own fate to a process that is clearly teetering on the edge of being out of control.