Microsoft Hangs Tight to Visual Studio Ship Schedule

by Alex Woodie

It had become a regular occurrence, much to Microsoft's chagrin: the regular, almost expected, delays of new products. Last summer, we all wondered when Windows XP Service Pack 2 would go out the door. It finally did in August, freeing the vendor to work on subsequent releases dependent on that SP2 code. Microsoft is facing similar dependencies today with Windows Server 2003 R2, Windows Vista, and Longhorn Server--not to mention SQL Server 2005 and Visual Studio 2005--but now it appears less inclined to delay releases.

Microsoft last week declined the request of Visual Studio 2005 beta testers to release a third beta version of that product, which would have pushed its final release past the November 7 ship date that Microsoft announced earlier this year. "There are still way too many bugs and performance issues" in the beta 2 release of Visual Studio 2005, says one developer on Microsoft's MSDN Web site. "I'd rather have a good product six months from now than a mediocre one in three months."

Numerous other developers chimed in to support this stance on Visual Studio 2005. "There are so many outstanding bugs and issues that a Beta 3 is required to ensure stability of the final release," wrote one developer. "All the bugs must be fixed," writes another developer. "This is not the old West way. This is a timely issue for the sake of the security."

Another developer asked Microsoft to get to work on a service pack, which the company has not issued for Visual Studio in recent years. "I have used enough of VS2005 to feel it will be ready for release on November 7. However there are still some annoying bugs here and there and probably more that will be discovered later. So the best compromise I can see here is to release on November 7 like announced but commit to release VS2005 SP1 within the next six months."

Others developers support Microsoft's intention to release the product in November. "Everyone sees large numbers of postponed defects and thinks 'wow, that's a lot of bugs not fixed,' and it is. But they don't do the same analysis that Microsoft Program Managers, Developers, and QA do to triage each defect that is postponed," he wrote, suggesting that people's perceptions of the amount of bugs is skewed because Microsoft, for the first time, has opened up its defect database for Visual Studio.

In the end, Microsoft decided to stick to its guns and shoot for a November 7 release of the final version of Visual Studio 2005. "Since the CTP, our team has worked very hard to get rid of bugs in order to bring you a high quality product. We are confident that we will be able to ship you a high quality product later this year!" the company posted to its MSDN site.

It wouldn't have been the first delay for "Whidbey," the codename for what has become Visual Studio 2005, or for "Yukon," the codename for the next release of the SQL Server database, which are being developed together. Whidbey and Yukon had been slated to ship by the end of 2004, but in the spring of 2004, Microsoft delayed that ship date to the first half of 2005. Earlier this year that ship date slipped to the second half of 2005, where it currently stands.

Microsoft's refusal to issue a third beta program for Whidbey should not come as a surprise. When it issued the Beta 1 of the product in April, it was so confident in the product's quality that it took the unusual step of issuing a "Go Live" license that enabled developers to start writing production applications with Visual Studio 2005 Beta 2, .NET Framework 2.0 Beta 2, and the SQL Server 2005 Express Edition April CTP (see "Microsoft Senses the Finish Line for 'Whidbey' and 'Yukon'").

Microsoft has faced similar delays with its Windows operating system. The last major Windows delay was last August, just before the software giant released Windows XP SP2 to manufacturing (see "Microsoft Delays Windows Server 2003 SP1 and 64-bit Version").

In order to prevent another delay to its operating system, Microsoft decided to start removing functionality from Longhorn (see "Microsoft Cuts WinFS from Longhorn to Make 2006 Ship Date").

Since that time, Microsoft has pretty much stuck to its release schedule, at least as far as Windows goes. Early April brought an impressive one-two-three punch of new operating systems, including Windows Server 2003 SP1 (see "Windows Server 2003 SP1 Now Available"), and then the Windows Server 2003 X64 Editions and Windows XP Professional X64 Edition at a Microsoft conference (see "64-Bit Windows Goes Mainstream at WinHEC 2005").

These days, all eyes are on Windows Server 2003 Release 2 (R2) and Windows Longhorn, which last month received the formal name of Windows Vista for the desktop version (the server version is still referred to by codename, Longhorn Server, although it seems likely it will be called Windows Server 2007). Windows Server 2003 R2 is expected to be released later this year, probably about the same time that we see Visual Studio 2005 and SQL Server 2005, which is November 7.

As we've seen with the delays of Windows Server 2003 SP1 and the X64 versions of Windows XP and Windows Server 2003, Microsoft's ability to ship Windows Vista and Longhorn Server is dependent on its ability to get Windows Server 2003 R2 out the door in a timely fashion. This linking of code bases enables Microsoft's developers to get more quality work done in a shorter timeframe. But, as we've seen, it also exposes the company to unexpected delays should part of the program fall behind.

Microsoft's new strategy of linking server- and client-side operating system releases has its benefits, says Jupiter Research in a recent report on Windows Server 2003 adoption. "The [code-base alignment] strategy will pay off for Microsoft in terms of maximizing development resources, improving operating system security, and accelerating cross-product integration benefits," writes Joe Wilcox, the lead analyst who wrote the paper. "However, the code-base alignment is one factor contributing to Windows Vista delivery delays, creating future release uncertainty."

Microsoft already has its work cut out for it when it comes to Windows Server 2003 R2, Jupiter says. According to its survey of about 250 medium to large Windows shops, one out of three Windows shops isn't even aware of R2, and another 25 percent, while aware of R2, have no plans to upgrade to it. This compares negatively to Windows Server 2003 SP1, which more than 50 percent of Windows shops have plans to upgrade to within two years.

Jupiter says this confusion about Windows Server 2003 R2 could hurt Microsoft and provide an edge for competitors, especially considering that some Windows shops that do not have Microsoft Enterprise Agreement licensing or Software Assurance upgrade protection will have to pay for R2. Windows Server 2003 SP1, by comparison, was free to all (because it was, in effect, a giant security upgrade that Microsoft deemed vital to the health of users systems). "Microsoft must step up its informational outreach to customers about the importance of Service Pack 1 and R2, and the differences between them," Jupiter concludes.