Robert McLaws: Windows Edition

Blogging about Windows since before Vista became a bad word

September 2004 - Posts

  • Microsoft Doesn't Own Monopoly on Slipping Ship Dates

    Microsoft's not the only one that suffers from slipping ship dates. The next 007 movie's ship date slipped from November 2005 to sometime in 2006. Maybe Microsoft should cut a deal with the companies that buy MGM to feature Longhorn prominently in the next movie. LOL. But that's not the only reason 007 is a lot like Longhorn. The next movie will probably be missing it's own key feature: Pierce Brosnan.

    So the new catchphrase is: Pierce Brosnan has been WinFS'd from the next 007 movie.

    PostTypeIcon
    2,580 Views
  • Help The Hurricane Victims

    All I can say is, I'm really glad that I don't live in Florida. But the people that do live there need your help. I can't even imagine what it would be like to live through four hurricanes within the same six weeks. The shelters are packed, and people need food and supplies. So please be as generous as you can, the holidays are coming soon. Click the links below to donate.

     

    PostTypeIcon
    2,187 Views
  • DNS Issues

    Somehow, over the past few days, my domain name registrar's DNS settings got all screwed up. For whatever reason, many of my domain names were parked, instead of pointing to my DNS servers. So some of you may experience patchy access to the site over the next 48 hours as the correct settings re-propagate across the web. Sorry for the inconvenience.
    PostTypeIcon
    3,155 Views
  • When FUD Becomes Journalism, or Avalon Is In Longhorn

    I don't get it. Why is eWeek trying to spread FUD by speculating on how developers might feel if Avalon was not in Longhorn? It's completely retarded. It's like asking someone in Phoenix, "How would you feel if an earthquake made California sink into the ocean?" or "How would you feel if Satan suddenly appearded before you in red silk panties and a whip and did the jitterbug?" (Personally, I'd probably feel like my doctor needed to up the dosage on my medication, but that's beside the point.)

    Avalon and Indigo are much more stable than WinFS is. I wouldn't be surprised if you see Indigo before the end of 2005, and Avalon not much longer after that. I mean, the PM of the WindowsForms team said that WindowsForms has about hit the limit of what it can do in Win32, and while it will stick around for a long time for compatibility, there likely won't be any new features post-Whidbey. With VS "Orcas" being the de-facto way to build apps in the "Longhorn" wave, and no significant new WinForms features planned for that version, it's pretty safe to say that the default way to build apps in Orcas will be Avalon, and that it will be "widely available" at release time.

    And any notions to the contrary are just plain hogwash.

    I think the quote by Somesgar was taken out of context. IMO, the statements he made were no more than responsible planning on the part of a VP. As I discussed previously, when you have so many dependencies between software packages, you have to be a lot more fluid in your planning. DonXML talked about being worried because there is no design-time story for Avalon yet, but that's simply because the VS team is still working on wrapping up Whidbey. There is no reason to build an Avalon designer yet, because it will more than likely require other IDE features that haven't even been spec'd out yet, much less written.

    The guy heard the quote and probably thought he had a story. It seems that the mainstream media is resorting more and more to making up stories to fill space, but this little piggy just doesn't fly. If Avalon missed a deadline and was late a month, Microsoft would push back the Longhorn ship date. WinFS was going to take a lot more than a month to fix.

    PostTypeIcon
    3,369 Views
  • Longhorn Shakeup - Part Two: The Death of the 'Software Wave'

    In my previous article, I discussed the social background behind last Friday's announcements, and the history that lead up to those decisions. Today, I'm going to talk about the demise of the synchronized software release. It's important to note here that these are editorials; an attempt to put the respective pieces together, based on my own experience and my interactions with the various parts of Microsoft. While I strive to maintain accuracy, I'd rather not get nit-picky over minute details, like for example, which version of the Windows codebase Longhorn is being built from.

    At PDC 2003, Microsoft talked in great detail about its ship schedule for the next 4 years. It was a very ambitious schedule, with several interim releases (XPSP2 and WS2003 R2) wedged in between two major "software waves". The first wave was called the "Yukon" wave, named for SQL Server 2005, code named Yukon. Microsoft's promise was to deliver a version of Visual Studio ("Whidbey") that was synchronized with the next version of SQL Server. After that came the "Longhorn" wave, which promised a version of Visual Studio version ("Orcas") synchronized with the next version of Windows, codenamed Longhorn.

    What was not talked about was the serious ramifications of attempting such a huge synchronization between development teams. It's a bigger deal than one might think. And it ultimately had a direct impact on the entire release schedule. Time to jump in the Wayback Machine...

    <insert wavy Wayne's World dream lines here />

    Lets jump back 3 months ago. The VS team was hard at work, and things were plugging along. Then, Microsoft executives drop a bombshell. "Yukon" development had run into some snags, which would end up pushing back the Whidbey release from late-2004 or early-2005 to mid-2005. True to form, most developers threw a temper tantrum, whining about how they wanted their tools now, blah blah blah. I think Microsoft needs to start handing out pacifiers with their PR announcements.

    But I'm getting off on a rant here. Anyways, I'm not exactly sure on these details, so if I'm wrong, don't ram it down my throat, but if I remember correctly, there were some issues with integrating the CLR into SQL that was holding up development. Why was this an issue? Well, lets take a look at the dependencies across the "Yukon" wave:


    Figure 1: Dependencies in the Yukon Wave

    So,the .NET Framework is the base, and Yukon has the CLR embedded in it. Oh yeah, and Visual Studio compiles against it. But what you may not have known is that the new features of Visual Studio are built in managed code, dependent on .NET 2.0. And did I mention that every single one of these parts were being developed at the exact same time? That would be a feat for ANY company to manage, especially one as large as Microsoft.

    So are you confused yet? Cause it gets better. Because the Longhorn wave follows the Yukon wave, any delay in the release of Whidbey automatically mean that there will be a delay in Orcas. Because, while Microsoft has Program managers who help manage features two and three releases out, large scale development of those features do not start until the release in progress is finished. And a delay in Orcas means, automatically, a delay in Longhorn. Speaking of which, let's take a look at the dependencies in the Longhorn wave:


    Figure 2: Dependencies in the Longhorn Wave

    As you can see, the model gets a lot more complicated. Lets see if I can explain it properly. First off, lets not forget that all these systems are being developed in conjunction with the Yukon wave, so all of those dependencies still apply.. Now, lets add Windows to the mix. All three pillars of Longhorn are being developed with a significant amount of managed code. And remember, the managed code base that they're working from is also still in development. Since the .NET Framework team is constantly kicking out new builds, it's entirely possible that each of the three pillar teams are working with different builds of the .NET Framework. If they're relying on internal features that are still in flux, a simple bug fix could have disastrous consequences.

    For WinFS, it's even more complicated. They're building on two systems that are still in flux... Yukon and the .NET Framework. In that scenario, it's entirely possible that the WinFS extensions are being constructed on a build of the .NET Framework that is entirely different from the one they are baking into the database, creating a whole new set of problems. This is why it was next to impossible to synchronize a Visual Studio 2005 build that could build Longhorn apps... they would have to have a significant, QA'd milestone from which to work with, namely Visual Studio 2005 Beta 1. Only after that build was released could you re-synch the teams, get everyone on the same versions of the Framework and using the same development tools, and move on from there.

    So at this point, you're going to say "Well, Microsoft is hemorrhaging cash. Why can't they just throw more money at the problem?" Oh, how short-sighted you are. Microsoft still has shareholders to answer to, and you don't just start throwing money around because you have a lot of it. It's real easy to acquire wealth. it's a lot harder to keep it. Just ask the hundreds of .COM companies that burst with the bubble. So throwing a couple million at the problem still doesn't solve the dependency issue. And with Yukon delays affecting the WinFS team just made it that much harder to overcome the problems they were already having. Again, you have to remember that WinFS is not just about search, just as Avalon is not just about XAML. WinFS is about a new file/metadata storage paradigm, from which ALL future Microsoft products will be built. WinFS is to information storage for the next 20 years of Windows as managed code is to Windows platform development over the same period. It's not something Microsoft can afford to get wrong.

    Lets think about the long-term vision of WinFS for a second. Think about all the Microsoft applications that store data in one form or another. You have a relational database in the file system. Forget needing MSDE or it's successor, SQL Server 2005 Express. Forget about having to deploy Access databases for simple applications... just add a new WinFS object schema (an XSD document) and store your data there. You won't even have to worry about application-specific APIs to get data out of OneNote, for example. Just use WinFS to grab the document, load up the data, and go. You could access Microsoft Money task items in Outlook (with the proper credentials, of course) synchronized with your other tasks. You could even store Visual Studio development tasks, culled from the Team Foundation Server database, and have those integrate with your calendar too. With the stakes so high, can Microsoft afford to listen to whiny, impatient developers? In this case, the answer is a most definite 'no".

    OK, so reports of the death of the 'Software Wave' has been greatly exaggerated. (Fooled ya, didn't I?) It's not exactly dead, but Microsoft has definitely learned its lesson. Since the successes of the 'out-of-band' approach with Windows Server 2003, Microsoft has had examples on both sides of the aisle on how to manage extremely interconnected projects. From this point forward, you will continue to see products released at the same time that complement each other. You might even see it continue to happen on such large scales as we've seen thus far. More likely, you'll see more 'features' broken out into their own 'products', that are re-combined into a future update (a la Windows Server 2003 R2).

    Now, notice that it didn't take long for even the most respected people in the industry to scream "Cairo" and doom WinFS to its death. Just remember, Microsoft's dream of a pen-enabled PC failed four times before it succeeded. The lessons from Microsoft Bob and the infamous Clippy went into making products like Windows XP and Windows Media Player 10 easier to use, and more effective. The lessons learned from the entire Longhorn process thus far, from PDC 2003 to blogging to software waves, will define how Microsoft develops software over the next 10 years.

    In my opinion, it's just another lesson in life. Do you shoot for the moon, dream big, and then risk coming up short from time to time; or do you always brainstorm within the confines of reality, listen to the pundits and the naysayers that work fervishly to convince you that it can't be done, and be guaranteed success? I don't know about you, but I can hardly recall an endeavor worth achieving that didn't involve dreaming big, high risk, and significant possibility of failure. And given the choice, I'll dream big every time.

    Next up: my predictions on what the Microsoft world will be like after 2006.

    UPDATE: I've disabled comments for now, because some Mac zealots resort to swearing to get their point across. For now, if you want to comment, blog about it and link to this post.
    UPDATE #2: Lets see if Mac enthusiasts can make a point without resulting to vulgarity.

    PostTypeIcon
    11,381 Views