Windows Confidential: Why Can’t We All Just Work Together?
One danger of designing an interoperability document is that you might find nobody wants to implement any of your specs.
Years ago, I was having lunch with several people from another project group within Microsoft. This wasn’t a planned thing. It was just something that evolved from a spontaneous decision to have lunch with a visiting colleague.
These types of informal lunch get-togethers are fun. I get to learn about other people and the projects on which they’re working. If I’m lucky, I can collect a few more stories.
Sitting at the table was one of the Microsoft representatives to an industry group charged with developing an interoperability document for something-or-other. The focus of the actual document wasn’t as interesting to me as the insight into the machinations of an industry group trying to develop an interoperability document.
He said the members of the group had split into two factions. The members of the first faction wanted to design an interoperability document that anticipated all possible requests and invented schemas to describe them. “What if a client wants to jiggle the frobulator when the flow is demodulated? We need to have a way to specify a modulation exception.”
The people in the second faction wanted to design an interoperability document that covered the important scenarios. Anyone reading the document could implement any scenario with reasonable effort. They would be able to get it done quickly, before all the vendors grew impatient and ran ahead with their own custom implementations, none of which would be compatible with any other.
The second faction believed it would be OK if the interoperability document didn’t cover every possibility. It would be effective as long as it didn’t preclude the ability to add support for those sorts of features in the future. My lunch table colleague belonged to the second faction.
Keep Everyone Happy
In response to this irreconcilable clash of philosophies, the industry group agreed to develop two documents. The first was a base document that covered the important scenarios. This satisfied the second faction. There was also an extended document that expanded the capabilities of the base document. This satisfied the first faction.
I suspect this stopped most if not all of the arguments over what should go into the interoperability document. Instead, the industry group members argued over whether a particular feature was a base feature or an extended feature.
The first faction would naturally argue that any new feature was a base feature. The second faction would naturally argue that any new feature was an extended feature. They could probably have resolved this by establishing that the people in the second faction were the “basic features sub-group,” and make them the final arbiters on what counted as a basic feature.
My lunch table colleague was exasperated. He said the extended document had become so complicated that the requests from the client began to resemble tiny computer programs. The server needed to execute those routines to determine whether or not to honor the request.
I half-jokingly suggested he propose adding a simple clause to the extended document: “If a request packet is received, evaluation of which would never produce a result (resulting in a denial of service if the server attempted to execute it), the server must reject the request with the error EWOULDHANG.” In other words, he would trick the industry group into requiring servers to solve the Halting Problem.
My lunch table colleague chuckled at the idea. “I’m so tempted to try that,” he said. I don’t know whether he actually did, but it turned out to be irrelevant.
The base document was eventually approved. Vendors started implementing the specifications. Work on the extended document continued for a number of years afterward. It eventually became clear from talking with vendors that none of them were interested in implementing anything beyond the base document.
After discovering this, the industry group formally suspended operations. All they had to show for their years of work was a mostly complete document that nobody cared about. The industry group had lost sight of the customer. They spent years working to design a specification that would never be implemented.
**Raymond Chen’**s Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history, Win32 programming and inadvertent car theft.