June 26, 2006
@ 03:33 PM

I was reading Charles Miller's post entitled We Come to Bury WinFS... where he wrote

The first thing to strike me about the blog post announcing the end of WinFS as a Vista feature is how totally un-blog-like it is.

Every comment (bar one) got the point. WinFS is dead. Its carcass is being split between SQL Server and ADO.NET, and the relational filesystem that was going to change the way we use computers is no longer just postponed to be shipped after Vista, it’s gone.

The blog post itself, however, is written entirely in marketing-speak. The engineer talks about how super-excited the team is about this "new direction", how encouraging this news is, and leaves the fate of Vista for a final, particularly obfuscatory paragraph. Nary a word is allowed to suggest that the last nail in the coffin for Vista’s most eagerly anticipated feature might be a huge let-down to those people who have been watching it slip further and further down the schedule since its fanfare announcement as a part of Longhorn three years ago.

Did Microsoft forget everything Scoble was supposed to be teaching them, so quickly?

Every now and then, you’ve got to put out a mea culpa. You’ve promised something that turned into something else, or that you changed your mind about, or that you just can’t deliver. In the mass-media world, you do this by spinning the story as positively as you can. The message will be filtered by intermediaries before it reaches the public, and it’s expected the journalists in the middle will get the point, pulling quotes from the positive spin to offset the otherwise negative message.

I agree 100% with Charles Miller's sentiments about the blog posting on WinFS. This seems to be another example a case where Microsoft overpromised and underdelivered failed to deliver but even worse instead of owning up to this, the blog post spins this as being what customers want. From reading the hundred or so comments and trackbacks to Quentin Clark's post it doesn't seem that there are many people who are excited or encouraged that what once was touted as a pillar of Longhorn is now just another checkbox feature in SQL Server. This makes Microsoft look bad to developers because it means that we are either insulting our developer customers by thinking we can pull the wool over their eyes in such a blatant way or even worse that we are completely out of touch with them. Either way, it sucks and I feel like we should apologise to developers and perhaps even the software industry as a whole. Microsoft did offer a mea culpa to developers for the delay between Internet Explorer versions and I think this is another one of those cases where we should do the same.

I feel like I should probably throw in some last thoughts about WinFS, the technology, especially since in my previous post I claim that this decision should have been made a few years ago. Below is a random collection of my thoughts WinFS which can also be gleaned from my various blog posts on the technology over the last few years

  1. There was a divergence of opinion in what the team was building and what the people thought the team was building. A common misconception was that WinFS would somehow make search "better" on the desktop in the same way that desktop search tools like Lookout do. I addressed this misconception further in my post Killing the "WinFS is About Making Search Better" Myth from almost two years ago.

  2. The project had the biggest example of scope creep I'd ever seen at Microsoft. When WinFS swallowed ObjectSpaces the team decided that instead of just tackling the hard problem of building an object/relational file system for Windows that they also wanted to tackle the hard problem of  building an enterprise-class object to relational mapping technology with the same product in a single release. It also didn't help that key ObjectSpaces folks like Matt Warren, Dinesh Kulkarni and Luca Bolognese ended up joining the C# team to work on LINQ which meant WinFS inherited all of the problems of ObjectSpaces but not necessarily all the folks who had been working on those problems.

  3. The chicken and the egg problem. One of the key ideas in the WinFS type system for the Windows desktop was that we'd have common file system level types for high level concepts like people/contacts, email messages or photos instead of just opaque bits on disk with some file format specific metadata. To take advantage of this, existing applications would have to be rewritten or new [backwards incompatible] applications would have to be written targetting WinFS. The primary benefits of making this change [besides the improved programming model] were the network effects if lots of applications used these types (e.g. Outlook stored mail identified by a WinFS contact, RSS Bandit stored RSS feeds from that WinFS contact, AOL Instant Messenger stored IM conversation logs using that contact, etc). Even if you got these network effects you then had to deal with the Windows registry problem (i.e. apps stomping over each others data which is one of the main problems with the Windows registry today).

  4. I never saw good answers to the questions Jon Udell asked in his blog posts Questions about Longhorn, part 1: WinFS and Questions about Longhorn, part 2: WinFS and semantics. Specifically, the world is betting big on open file formats such as XML including parts of Microsoft (e.g. Microsoft Office) so why would anyone want to build aplications targetting a proprietary Windows-only file system that didn't have a good XML story for getting data out of the platform?

I should probably stop now. Even though all the information above is freely available to anyone who reads blogs and can put two and two together, some may object to the above collection of thoughts.

Monday, June 26, 2006 5:21:54 PM (GMT Daylight Time, UTC+01:00)
This is a very good summary of my thoughts about WinFS, as well.

"Even if you got these network effects you then had to deal with the Windows registry problem (i.e. apps stomping over each others data which is one of the main problems with the Windows registry today)."

We're going to have to disagree here. The biggest problem with the registry is NOT that applications stomp on each other's settings. The only registry settings that get stomped are the application associations and the COM registration stuff. While both of those can be problematic, they are nothing compared to the REAL problems with the registry. What are the problems? I think it's Documentation, Cruft and Versioning...

There is SO little documentation on WHAT should be in the registry (and what shouldn't), there is SO little documentation of best-practice, so little documentation of what Windows itself puts there, so little documentation of what various applications stuff in there, that it's just a huge mess of random data. Without Don Box and kin, we would have NO IDEA what COM needed in the registry. Without Mark Russinovich and gang, no idea what settings most applications use. This is Microsoft's fault, they set the trend.

My registry is filled with noise; settings that have accumulated since the last time I repaved this machine (which is a VERY SCARY 4 years now!). Can you guess what the size of my registry is? Can you guess how many obsolete settings there are in there? I can't, and I really don't want to find out by going through the extreme pain required to move everything to another machine. With no documentation, and a Microsoft-driven monkey-see-monkey-do about the documentation, uninstall, and just general use; application developers have no idea what is safe to remove, no reasonable way of tracking what used to be there to restore it, and no idea if that restoration would even be safe due to later installations of updates, patches and such... so it just stays and builds up.

Which brings us to versioning. How much pain is caused by the installation of parallel versions of applications, or the parallel installation of programs that handle the same sort of files? Short of a VPC, can you really have IE 5.x, IE 6.x, IE 7.x, etc. on my machine for cross-browser testing? And that's just a viewer of web-pages... things that are supposed to be be cross-platform by design! How about the story for handling the upgrading of any Office application? How much cruft in my registry is the result of what ISN'T safe to remove in case this latest version needs to be uninstalled? How many settings related to tweaking a bug out of Word 6.0 are still read and supported by Office 2007, and how many times has that code-path been tested. The whole structure of COM registration is broken because of this.

So, what does this have to do with WinFS? Tons... to this day, we still don't have the versioning story right (heck, they're changing the verioning load policy for CLR 3.0--yeah! finally a minor-minor version change is transparent!) When the CLR was first announced, I stood up at that Microsoft conference and asked POINT BLANK what the versioning strategy for the new "super cool" (binary or XML) serialization of POCOs was. You know what I got? The promise that it would be easy, and that the platform itself was going to show us the way to make our applications resiliant to upgrades and mix-version deployments. Little to no examples of that exist EVEN NOW. Instead, we're getting yet another UI platform in WPF where we have to reinvent (or wait for) all the same basic controls we've all waited for over and over. The versioning story? MIA.

Again, what does this have to do with WinFS? The idea that we could EVER store anything with a common schema (that's coming real-soon-now) in a version resiliant way (coming soon to a framework near you) for common entities (coming soon in WinFS). So why would I ever expect to see a resonable story about versioning and best-practice for the use of WinFS? It's certainly not going to be there in 1.0, and Microsoft doesn't have much credibility FOR the developer with regard to actually tackling the hard problem of versioning. The Office folks, the SQL Server folks DEFINATELY keep datacompatibility, but the techniques and practices for the ISVs are not documented in a form we can learn from.
Comments are closed.