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.