Now blogging at diego's weblog. See you over there!

two steps forward, one step back

Reading this article ("Longhorn goes to pieces"), any number of paragraphs stand out, for example:

Advanced search features that Gates has termed the "Holy Grail" of Longhorn, the next major version of Windows, won't be fully in place until 2009, Bob Muglia, the senior vice president in charge of Windows server development, told CNET
And I immediately remembered my post from last year on Cairo and WinFS, where I said:
Seriously now: To anyone that might say that the technology could not be built... please. Microsoft is one of the top engineering organizations in the world. NeXT could do it. Why not Microsoft? The only reasonable explanation, as far as I can see, would be a realignment of priorities and the consequent starving of resources that go along with it (which is what killed both OpenDoc and Taligent, for example). Which is all well and good.

But then the question is: could it happen again?

Probably not--then again, never say never.

2009? Wow. I keep wondering if this is because they start in a direction and realign the schedule, or simply because there are parts of the vision that are spoken out loud but never properly defined.

But another possibility that comes to mind is that Microsoft's intent of Windows vertical integration that it makes it harder to build these components. Wouldn't it be an idea to work on this thing as a completely separate component, and then let the features percolate upwards into the UI over time? (Of course this idea must have been considered, but put another way, is there any technical reason why it shouldn't be done like this? I can't see one.)

I say this because monolithic design is a tendency difficult to avoid, and this has been very much on my mind lately. You start pulling pieces together (for different reasons) at compile-time, and before you realize it you en up with a set of highly interdependent binaries. (Regardless or language or platform, all modern platforms support dynamic binding to different degrees). And it's deployment where things start to slip, because it's there that the potentially different versions of a component have to be reconciled. In other words, deployment is one of the largest half-cracked nuts in software development.

What I realized recently is that deployment is not a separate problem within an application's life-cycle, it is integral to the UI of the app. Deployment should be properly defined from day one, and the goals set for it have to be pursued in parallel with the rest. An installable app or system should be the target from day one. Because, from the moment a user sees your screen, it's your UI. What they have to do to keep up to date, to install or uninstall components or the whole system, and so on. Java for example has a problem in this sense, but no platform is perfect.

Anyway, just a thought for the day. :)

Posted by diego on May 15, 2004 at 11:30 AM

Copyright © Diego Doval 2002-2011.