Yukon and Whidbey: a marriage not worth fixing

eWeek has an article about the release date slip of Yukon and Whidbey. It's more an article about Yukon than about Whidbey and for a reason: it's a known fact that Yukon holds back Whidbey, not the other way around, so if Yukon slips, Whidbey will slipperdy slide with it.

From the article:

According to Rizzo, both products are on the same timeframe for shipping for a key reason: Namely, Microsoft wants to release the best of its developer tools with the best of its database technology "to really change the industry," he said. "If you look at Oracle [Corp.] and IBM and other competitors in the open-source space, they don't have releases where new and innovative tools are released with a new and innovative database. Customers want that: the next generation of tools that exploit the next generation of database technology."

This re-vamped some thoughts I have had for a long time: is it truly a Good ThingTM that Yukon and Whidbey are released at the same time? And if it is a good thing, for whom is it 'good' and for whom is it less 'good' ?

Let me say it my way: it is a good thing for Microsoft and a bad thing for developers.

The reason for this is: developers really need an update to Visual Studio. Because Visual Studio.NET is tied to a particular .NET version, a slip of the VS.NET release date will also make .NET 2.0 slip further away. Due to the current not-all-that-bugfree state of the VS.NET 2003 IDE, it is key that developers get their hands on Whidbey a.s.a.p. Talk to an ASP.NET developer and you know why. Talk to people who want to get started with generics and better editors and you know why. Furthermore, do all those developers write software targeting SqlServer and do they need VS.NET to target SqlServer? I don't think they all do. So do they really need Yukon together with an update of VS.NET? No, not at all. Only if they've decided to target Yukon. If they have to work with a production SqlServer 2000 or even SqlServer 7 or Oracle 8i/9i system, they don't need Yukon at all. But they do need Whidbey because of the vast amount of improvements and bugfixes.

Why is it a good thing for Microsoft? To tie Visual Studio.NET with Yukon, Visual Studio.NET can increase Yukon sales. Visual Studio.NET is the tool used the most for .NET development. If Visual Studio.NET has by far the best integration with Yukon compared to Oracle or DB2, it might be an extra benefit for Yukon so project teams might decide to opt for Yukon instead of the competition.

Looking at the marriage between Yukon and Whidbey, I can only say: stop the councilling, get a divorce and start seeing other people, because it will only affect the happiness of the children and friends. It's nice that Microsoft tries to make more money by pushing Yukon through Whidbey, but for developers, a development environment is a toolset used to write software, not an extension of 'a' database. However, because of delays in the Yukon department, Whidbey is delayed too, which is very sad news for .NET-targeting developers.

Other sad news is that MS apparently has cut some serious enterprise features from Yukon. It might look like a lot of SqlServer users don't need serious enterprise features, but current users of Oracle and DB2 on big machines do need those features, however are of course not very eager to migrate to Yukon if they have to drop serious enterprise features for that because Yukon doesn't support them. I really wonder why MS can't pull it off. Yukon is already more than 5 years in development, SqlServer 2000 wasn't and still isn't a bad database, so what's the showstopper in Yukon that it is delayed so much? Is it CLR integration? Or is it something else? I find it bad news that MS can't get Yukon ready on time, because it means that development was problematic which can only lead to a problematic end result. Because I like SqlServer, that's not something I'm looking forward to.

Perhaps MS could consider releasing an SqlServer 2000 SE version with just MVCC features, a better toolset and an earlier release date of Whidbey, thus ending the marriage between Yukon and Whidbey for good.

21 Comments

  • VERY well said.



    While UYKON is "nice to have", I would go very far to be able to work with ASP.NET 2.0 and generics NOW. MS really tries to synchronize way too many different things into one release date at the moment - this is really not good.

  • Same here!!!!



    I have been reading about all the *CORE* updates in .Net 2.0 and wishing I had them today.....



    while I agree that the next sql server rev is a very important milestone I think I need the VS and .Net updates first, let SQL server slide

    it's not like I can up and swap that real fast anyway.



  • I guess this is one of the flaws of letting people know what's coming. Given the amount of info available on Whidbey they can't blame anyone if we want it soon, because people are given the impression that it's nearly finished ...



    Maybe developers are no different than customers after all ;)

  • .NET 2.0 is ready, Whidbey is ready, but just because of Yukon, Microsot don't release them. What if I don't use SQL Server? Better, I'm not too sure SQL Server 2000 clients will jump straight to Yukon...

    This is purely marketing, and it slows down the technological improvements.

  • What I also find weird is that NONE of the MS bloggers has mentioned a single word on this. Did they simply find it not important or is it a corporate policy? I find it really weird as it will cause a major problem for a lot of developers, because as you said it so well Martin: it will become a hard sell in the long run.



  • I am not surprised. Typical mass scale FUD from the Redmond thieves always have a downturn.



  • in a perfect world, I would agree with you, Frans. However, MS doesn't exist in that world.



    First off, Whidbey isn't even in BETA yet. You guys are talking about it like it is finished and sitting around waiting for Yukon, which is far from the truth. When Whidbey hits beta 1, the talk above still won't be true nor appropriate.



    Second, VS2002 has been out a little over 2 years and you see how bad off it is. Releasing VS2005 early is going to put it in the same position. Sure, there will be new features and some bugs in VS2003 will be gone but there will be a whole new crop of bugs in the new features and you'll be in the exact same position you're in now: using a product that has potential for greatness. If they take the time to FINISH Whidbey before they release it, we'll all be better off.

  • Shannon: I see your point, however Whidbey is not in a shabby state at the moment. remember, the PDC build was from august/september last year. I'm pretty confident that they would have made the Q4 2004 deadline.



    I agree that rushing the stuff will do no good, but delaying it will neither: what to do with teh time? Add features which were cut because of the timeframe for 2004 ? Or re-test everything?



    I think a release when it is done is best: let's say it is done at the end of 2004. Release it, a LOT of people will start using it and after 3 months fix the bugs which weren't ironed out during beta testing. Beta-testing might sound great but not a lot of people do it, not with production type of work.



    However fixing teh bugs after a release is something they haven't done since vs.net 2002 has been released...

  • :-) "Redmond Thieves" is a patented trademark "anon".

  • I agree Frans. Give us Whidbey ASAP! If there are a few features that depend on Yukon, that can't be immediately used then so be it.

  • It should be that when yukon comes out, it installs or has a separate installer for the tools to develop software with visual studio.net. So people who use Oracle are not waiting for whidbey which will contain all nice tools they'll never use and which are only used by yukon customers, the ones which can use that separate installer anyway.



  • Fix the bugs in the current version! Frans, I know you've blogged on this before.



    Right now I'm still pushing clients to go from NT4 to Win2k, from nothing to .Net Framework 1.1, and from SQLServer 7 to 2000.



    I'm going to be dealing with today's technology today, and for years to come. I also suspect that new versions of VS will fix some bugs (not all, as you have noted in regards to VS.Net 2002, Frans), and introduce new bugs, so what's the point in hanging out for it?

  • I wonder if there are a lot of existing ASP.NET developers waiting for ASP.NET 2.0.

    I wonder if ASP.NET 1.1 code will be compatible with ASP.NET 2.0, or, if you'll have to port the existing code to ASP.NET 2.0.

    I've VS.NET Whidbey on my computer installed, and ASP.NET 2.0 looks very different from ASP.NET 1.1.



    For now, ASP.NET 1.1 code does not run with aspnet_isapi 2.0...

  • "Whidbey is not in a shabby state at the moment"



    I have seen no evidence that your statement is true, Frans. I just returned from DevDays and I saw 3 different builds of Whidbey, all alpha, none with the full functionality, none stable enough to call "beta". Only 1 had Whitehorse. Only 1 had the VB.Net Class designer. The words "this is only an alpha" were repeated over and over and over by both presenters using Whidbey.



    Yes, the PDC Alpha build is from August, the same time as the Yukon Beta PDC refresh. But that build is the last version of Yukon I've seen so I can't say how much progress has been made in Yukon, but the newer builds of Whidbey I saw today were impressive as far as the intended feature set but were still too shabby for your post to hold water.



    NOTE: I do not have any Whidbey build other than 30703.27 and I do not know anyone at MS who knows the true state of things, so I could be wrong, but I have yet to hear/see anyone with any evidence that Whidbey is at the beta level yet. Someone please correct me if I am wrong.

  • (I posted this comment also in Jeff's blog as reply on your comment there which was similar to this one ;))



    Shannon: Within a few weeks the alpha tester group gets new bits of whidbey, we'll see what's true / false of what's working and what's not.



    It's definitely not feature complete as new features are still debated in the alpha tester forums, but it gets close. Being not-feature complete means that it is not beta yet. Beta 'quality' means nothing btw. Beta means: feature complete, let the testing begin.



    Whitehorse is an add-on to vs.net, not a main part. Whitehorse was barely runnable in the first alpha we saw. But it's March, not October.



    No matter what, the pushback of the release date creates a big problem. ASP.NET development IS broken in vs.net 2003, the HTML editor is horrible. It might sound weird, but ASP.NET is the major .NET feature which makes people use .NET in the first place: a lot of websites currently using ASP and for example Oracle are ported to ASP.NET.



    If developers have to wait for more than a year before a decent ASP.NET editor is released, what to do? And don't expect a 3rd party editor which solves the problems: any 3rd party editor developer knows that ASP.NET 2.0 totally changes the picture.



    As an O/R mapper vendor I should be glad Objectspaces is pushed back for more than a year. In a wicked way I am, but just a little, and for the most part I'm not all that happy with this delay. .NET 2.0 solves a lot of problems and can bring a lot of good things I really need but now I have to wait for a long period of time before I can start updating the code with f.e. generics, true IXmlSerializable support, design time databinding of my objects etc.



    -------

    So within a few weeks we'll know if whidbey is almost feature complete or not. personally I didn't expect a beta before June, when Teched europe is held, however if it goes beta in june, it can RTM before the end of the year.

  • "As an extra note, I would've ranted about how the framework is done. Why can't we just get that and start developing with it? Is VS a requirement for the framework? No. But, we get to wait for Visual Studio to go final before we get the framework. That's what I don't consider fair. "

    You have to use vs.net 2005 or notepad, because you can't compile code for .NET 2.0 from vs.net 2003

  • ::You have to use vs.net 2005 or notepad,

    ::because you can't compile code for .NET 2.0

    ::from vs.net



    I bet this could be fixed by someone at MS in less than a week. Compilation is easy, debugging is the problem - and the designers.

  • ... and the CLR used by VS.NET itself. You also run into this issue if you want to compile against 1.0 from VS.NET 2003 and you solely reference 1.0 assemblies in your solution: it gives wacky errors

  • "It might sound weird, but ASP.NET is the major .NET feature which makes people use .NET in the first place"



    Not weird at all, why would it be? ASP.NET is how I came to .net (and VB.NET). What seems weird is that you make it seems like ASP.NET doesn't exist right now.



    And I think it is weird that a beta in June will mean a RTM by December. Sure, it is possible, but I would recommend against it for the reasons I stated in my post the day the news was sent: MS releases their products too early. You know this, you've been complaining about this for years and still are. Beta in June and RTM in December means the first REAL release will be SP1. Microsoft needs to get out of that habit. Especially for tools like this where the chances of them EVER fixing the problems seem to be slim.



    I also disagree with your (and MS's, if that's where you got it) assertion that Beta 1 will be feature complete. That just isn't the way MS works. I'm not saying it isn't the way they work now and in the future (that would be nice) but I have yet to see a Beta 1 from MS where this was the case.



    And, as a total aside, I have yet to see anyone say that Yukon is holding up Whidbey and not that Whidbey is holding up Yukon. The only quote in the eWeek article simply said that the 2 were going to be released at the same time.

  • I posted this in Dan's blog:



    "You know, I just want one thing fixed in VS.NET 2003 if I have to wait for Whidbey. I wish that changing from html view to design view and back to html view wouldn't destroy all the careful formatting I worked so diligently to do. I mean, don't you think it's a little strange to tout the fact that whidbey doesn't mess up your code, as a feature? I would love to be able to switch to design view to double click a button to help me build events quicker, but doing so requires me to make a copy of my html code so I can replace the broken code that changing to design view creates. Doesn't that sound like a bug? Shouldn't developers who use VS.NET 2003 expect that bug to be fixed? Is that too much to ask?"

  • This pretty much explains the troubles.



    MS has decided that VS.NET 2002 / 2003 are "done" and is now delaying whidbey, although 2002 / 2003 are mediocre at best having some SEVERE issues.



    I don't get it. They should get their act together and fix the whole thing. I want generics, I want to be able to replace VS.NET versions - at least limited - and I do NOT want a total tie in with yukon.

Comments have been disabled for this content.