As you surely know by now, Visual Studio 2005 shipped in November, safely meeting Microsoft's self-imposed end of the calendar year deadline. Or did it? Let's take a look at some of the bits coming out of Redmond these days:
»Team Foundation Server 2005 is just now entering the Release Candidate stage, and is promised to ship in March.
»Atlas, Microsoft's implementation of AJAX functionality on top of ASP.NET is starting to drop Community Technical Preview builds that work with .NET 2.0.
»MSBee, a utility that adds the much-demanded feature of building .NET 1.1 projects with MSBuild, is out in Beta 1 form.
»Visual Studio 2005 Web Application Projects make ASP.NET 2.0 projects behave much more like ASP.NET 1.1 projects, removing much of the confusion that some developers had faced in dealing with Microsoft's total revamp of the way that things worked in the new release.
»Visual Studio 2005 Service Pack 1 is targeted for release in the third quarter of 2006.
What's going on here?
From the outside, it looks to me like there are three forces at work here. And try as I may, I can't put a cynical spin on all of them.
First, as anyone who was on the beta knows, the Visual Studio 2005 beta was long and sometimes difficult. Microsoft made it very easy for testers to report and check on the status of bugs; the flip side of that was that it was easy for testers to see how many bugs went unfixed as the release date of the product neared. Last summer some very vocal testers were even demanding an additional formal beta release, which would have pushed the actual release date out of 2005 and into 2006. This didn't happen, of course, with the result that it's now difficult to shake the perception that the product really did ship early. So one explanation for the continuing flow of pieces that could have gone into the box is simply that Microsoft was determined to make their ship date, and that they just wrapped up what was done in November and shipped it. Now we're getting the leftovers.
The second factor is that a moving target is harder to hit. Innovation in IDEs and development in general is moving at a fairly fast clip these days, and if you only release your product once every two or three years, you're going to look very obsolete towards the end of the product lifecycle. This works both ways. The more bits of extra innovation Microsoft releases off-cycle, the harder it is for other IDE creators to keep up. But the more projects like Eclipse keep up their own stream of continuous innovation, the more Microsoft is forced to continuously polish the Visual Studio image to keep it looking fresh and innovative. Fortunately, we developers benefit from the steady supply of new toys to play with.
Finally, I wouldn't discount the fact that the developers on the Visual Studio team simply love their jobs and the software that they produce. While some of the pieces rolling out now are official releases (notably Team Foundation Server), a lot of the others appear to be side projects or skunkworks efforts. With all the work that went into building extensibility APIs for Visual Studio, it would have been pretty surprising if no one on the team took up the challenge of extending it. When developers get an itch, they write code to scratch it, and sometimes that code is worth sharing with the rest of us.
Couple these factors with the omnipresent Internet, and you get the situation we have now. Software releases are no longer something that happen at a single specific point in time, even though we still have the grand announcements and giant parties to mark that arbitrary point. Instead, for major products, they've become an ongoing continuous process. While this brings new challenges (notably that of managing workstation configuration to make sure that you always have a known, stable platform to do your work with), on the whole it means that we get more functionality in our hands on a more timely basis. That can only be a good thing.
Mike Gunderloy is the Senior Technology Partner for Adaptive Strategy, a Washington State consulting firm. You can read more of Mike's work at his Larkware Web site, or contact him at MikeG1@larkfarm.com.