What Will You Want to Undo Tomorrow?

When we used to draw block diagrams of the PC architecture, back in that other century, the operating system would be a horizontal layer immediately above the hardware; the applications would be the next tier up, a row of adjacent blocks on top of the OS layer, having the status of peers with each other and clients of the operating system.

If you updated a piece of the operating system, all of the applications would see that new facility. If interfaces were correctly preserved, the applications might all work better; realistically, some of them would work better while others (the ones that broke the rules, and coded to internals instead of to published APIs) would be broken. But we all knew what the rules were.

Alarmingly, it looks as if its no longer possible to draw these diagrams as horizontal layers, with the boundaries of those layers clearly defined by published rules. The new diagram looks more like the Towers of Hanoi, the classic game (whose solution first taught me the concept of recursion) that requires things on top to be removed before anything farther down the stack can be changed. This says nothing good about the future of desktop or mobile computing.

Im talking, specifically, about the new approach to modularity--or rather, lack thereof--that we see in the remarks of Microsoft product manager David Caulton, who explained the absence of an Uninstall procedure for Media Player 9 with the following shocking example: "As with any OS component you might upgrade, everything has to go back sequentially together. If I install Windows Media Player 9 Series beta and Office, and I roll back, that would be to a pre-Office state."

Oh.

So, its now official: Not only is Office an "OS component," not a suite of applications, but the topology of Windows really is one big giant hairball (officially, "a single, integrated product"). If you want to replace the next-from-outermost layer, you have to untangle the outermost layer first. "The more users that can be informed thats the method for going back, the better," emphasized Caulton. Hes right, but perhaps not in the way that he intends: Platforms that dont impose this model may be the beneficiaries.

I wonder if Caulton realizes how completely unacceptable this attitude will be to enterprise IT. It comes from the same company whose Undo facilities in applications can only undo actions in sequence: If you think about it, when I change a word and then change the style of a paragraph, for example, I should be able to pull down a list of past actions and undo the typing without affecting the subsequent formatting action.

But its no doubt easier to implement as a simple stack--and within the context of editing a single document, we can probably live with that. If were supposed to take seriously the ideas of Web services, however, with their potential combinatorial explosion of interactions between cooperating (or, perhaps, competing) distributed agents and processes, then its clear that we need to be able to change modules in a mix-and-match manner--not be forced to undo an arbitrarily long list of configuration changes to get at one thats several steps in the past, only to rebuild the stack after making the only change that we really wanted to make.

Its a matter of discipline. Buyers must demand it, or expect that vendors will continue to be guided by their own convenience.

Tell me how youd like vendors to draw their road maps.