This post originated from an RSS feed registered with .NET Buzz
by Dan Fernandez.
Original Post: Visual Studio 2005 = "Whidbey"
Feed Title: Dan Fernandez's Blog
Feed URL: /msdnerror.htm?aspxerrorpath=/danielfe/Rss.aspx
Feed Description: Dan discusses Dot Net.
I'm probably the last person to blog about this, but in case you didn't know, Whidbey will officially be Visual Studio 2005.
Date Slip I wanted to take a second to respond to Frans Bouma and other bloggers who are “hooked“ on Whidbey and want to know why they can't have Whidbey now. Yes, the next release of Visual Studio will be a major release with lots of features that developers have been asking for and it will make your life easier. The problem is that you've only seen a partial view of what's coming down the road. The version of Visual Studio “Whidbey“ that was given to attendees at PDC was a technology preview. It is not feature complete. I think you can only really start to understand the scope of everything that Microsoft will be offering in Visual Studio 2005 by Beta 1. Until then, your basically looking at a car in an assembly line saying how you need the comfortable seat now, but we haven't welded doors on the car yet, we haven't done safety tests, and there's no turbo fuel injection (PS: you'll love the sunroof). To the specific point about Yukon delaying Visual Studio, I can assure you that the developer division isn't just sitting around waiting for Yukon to be ready, there is plenty of work to do, I just can't tell you about it until Beta 1 :)
I may be pointing out the obvious here, but I think that it's hard to judge timeframes for very large software projects and Microsoft doesn't do the best job at it. Features change and evolve, as do requirements, interdependencies, performance criteria, and much more. We have lots of smart people doing their best to manage this and we don't always make the exact software deadline. To give another recent example, Windows Server 2003 had around five different ship dates and about the same number of name changes. I'll do my best on keeping the name changes minimal:)
Go Live license? If you are interested in deploying Whidbey pre-launch, I can't say for certain, but we might redo the Go Live license system that we did with the VS 2002 launch. I don't know the details on this (if any 'softie does, please reply), but when I do find out, I'll make sure to blog it.
Visual Studio Service Packs WRT your point about why there have been no service packs for VS, first realize that we have several hotfixes up at http://support.microsoft.com if you have a particular problem to address, feel free to contact me directly. I think you should understand the context of what's going inside Microsoft as there has been a lot of work in making Windows XP Service Pack 2 a great service pack with a focus on security. As you can imagine, there are obviously lots of tie-ins and dependencies on the work being done in this service pack that would affect the developer division. You can read all about the developer implications of Windows XP SP2 here. I don't work on the Visual Studio servicing side (anyone who does chime in here), so I'm just giving you an educated guess here, but since there are specific developer implications for Windows XP SP2, the VS team would need to factor/depend on those changes for any future Visual Studio service packs.
Does Microsoft Give Access too Early? After reading these posts on Whidbey and in thinking about the backlash on Longhorn (too much info too early), it occured to me that maybe its not such a good idea to give the broad developer community early access to code. I'm not saying this because we don't value everyone's opinion, but because it might be dangerous to set such high expectations. What happens when you see a great feature and you see that it won't be available until the next release? Some features you like may or may not make Whidbey, it's a technical preview, we really cannot give any guarantee as to what the final product will look like. As Jay points out, we're even starting to give developers interim builds in a continuous effort to make Microsoft more open to developers. I would assume this would be a good thing, but there is risk in this approach. The risk is that we over-promise and under-deliver which leads to developers being angry, which is the exact opposite of what we're trying to achieve. For example, Beta 1 of the original PDC builds of what became Visual Studio.NET 2002 had E&C support for VB, but due to the amount of work required to get it right, it didn't make VS '02 or '03 and is only now being be added to Whidbey. Maybe the other problem is schedule expectations. We announce software ship dates, and then have to change them, potentially multiple times. If we hadn't specifically said that Whidbey would be released at the end of 2004, would that have been better? I don't know the right answer to this, but if you have feedback, let me know.
Previous Topic
