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.
About the Author
Mike Gunderloy has been developing software for a quarter-century now, and writing about it for nearly as long. He walked away from a .NET development career in 2006 and has been a happy Rails user ever since. Mike blogs at A Fresh Cup.