Url: http://www.proudlyserving.com/archives/2004/12/…

I really like this post by Adam Barr in response to Scoble’s blog about what happened to WinFS.  I think Adam is right on with his take on how long-term projects are scheduled.  Whether this is what happened to WinFS or not is up to speculation…ok…let me speculate.

WinFS was not a simple project with no or few dependencies.  It was dependent on the Yukon team including features that they needed in the core of the storage engine (e.g. Row-level security).  At the same time they had to convince the Longhorn UI folks to use WinFS for their desktop  changes.  Of course, the problem here is pulling from one team, and giving the other team an incomplete tool.  WinFS was doomed to failure because of this.

When I wrote the two WinFS articles (1 and 2) for MSDN.com, I tried to make sense of the data model they had come up with.  Frankly, the data model between drops one and two were very different, with the second drop being barely usable (from an intuitive point of view, not a bug point of view).  So carving out stubs that the LH UI team could use just confused the situation IMHO.

Don’t get me wrong, I know what they were trying to do with WinFS was hard, very hard.  Sure anyone can write a property based data store, but making it fast enough and feature complete to compete with NTFS is a huge challenge.