La vie secrète de Windows : Pourquoi ne pouvons nous tous simplement travailler ensemble ?
L'un des risques à créer un document d'interopérabilité est que personne n'implémente vos spécifications.
Raymond Chen
Ans, je faisais déjeuner avec plusieurs personnes d'un autre groupe de projet de Microsoft. Ce n'était pas une chose prévue. C'était juste quelque chose qui a évolué à partir d'une décision spontanée de déjeuner avec un collègue de la visite.
Ces types de rencontres informelles déjeuner sont amusants. J'arriverai à en apprendre davantage sur les autres personnes et les projets sur lesquels ils travaillent. Si je suis chanceux, je peux recueillir quelques histoires plus.
Assis à la table a été un des représentants d'un groupe de l'industrie chargé d'élaborer un document de l'interopérabilité de Microsoft quelque chose-ou-autre. L'objectif du document réel n'était pas aussi intéressant pour moi que l'aperçu les machinations d'un groupe de l'industrie à élaborer un document de l'interopérabilité.
Il dit que les membres du groupe s'est séparé en deux factions. Les membres de la première faction voulaient concevoir un document de l'interopérabilité qui prévoit toutes les demandes possibles et inventé des schémas pour les décrire. « Si un client souhaite jiggle la frobulator lorsque le flux est démodulé ? Nous avons besoin d'avoir un moyen de spécifier une exception de modulation ».
Les gens dans la deuxième faction a voulu concevoir un document de l'interopérabilité qui couvraient les scénarios importants. Quiconque lit le document puisse mettre en place un scénario avec un effort raisonnable. Ils seraient capables de faire vite, avant que tous les vendeurs se sont montrés impatients et a couru à venir avec leurs propres implémentations personnalisées, dont aucune ne serait pas compatible avec les autres.
La deuxième faction pense que ce serait OK si le document de l'interopérabilité n'a pas couvrir toutes les possibilités. Elle serait efficace tant qu'il n'a pas empêcher la possibilité d'ajouter le support de ces sortes de fonctionnalités à l'avenir. Mon collègue de table déjeuner appartenait à la deuxième faction.
Garder tout le monde heureux
En réponse à ce choc irréconciliable de philosophies, le groupe de l'industrie ont convenu d'élaborer des deux documents. Le premier est un document de base qui couvraient les scénarios importants. Cela satisfait la deuxième faction. Il y avait également un document étendu que l'expansion des capacités du document de base. Cela satisfait la première faction.
Je soupçonne que cela a cessé la plupart, sinon tous les arguments sur ce qui devrait aller dans le document de l'interopérabilité. Au lieu de cela, les membres du groupe de l'industrie a soutenu plus de savoir si une fonctionnalité particulière est une fonctionnalité de base ou une étendue.
La première faction aurait naturellement soutiennent que toute nouvelle fonctionnalité est une fonctionnalité de base. La deuxième faction aurait naturellement soutiennent que toute nouvelle fonctionnalité était une fonctionnalité étendue. Ils probablement pourraient pas ont cela résolu en établissant que les gens dans la deuxième faction ont été « sous-groupe des caractéristiques de base » et rendent les arbitres finales sur ce qui compte comme une caractéristique fondamentale.
Mon collègue de table déjeuner était exaspéré. Il dit que le document étendu est devenu tellement compliqué que les demandes du client a commencé ressembler à des programmes informatiques de minuscules. Le serveur nécessaires pour exécuter ces routines afin de déterminer en l'honneur de la demande ou non.
J'ai suggéré moitié humoristiquement il propose ajouter une simple clause au document prolongé: « si un paquet de demande est reçu, évaluation qui n'aurait jamais produire un résultat (conduisant à un déni de service si le serveur a tenté d'exécuter), le serveur doit rejette la demande avec l'erreur EWOULDHANG. » En d'autres termes, il serait tromper le groupe industriel exigeant des serveurs résoudre le problème de mettre un terme.
Mon collègue de table déjeuner ricané à l'idée. « Je suis donc tenté d'essayer ça, » dit-il. Je ne sais pas si il a fait réellement, mais il s'avéra être non pertinent.
Le document de base a été finalement approuvé. Vendeurs a commencé à mettre en œuvre le cahier des charges. Travailler sur le document prolongé pendant plusieurs années par la suite. Finalement, il est devenu évident de parler avec les fournisseurs qu'aucun d'entre eux n'étaient intéressés à mettre en œuvre quelque chose au-delà du document de base.
Après cette découverte, le groupe industriel a officiellement suspendu les opérations. Tout ce qu'ils devaient montrer pour leurs années de travail était un document complet surtout que personne ne s'intéressait à la. Le groupe de l'industrie avait perdu de vue du client. Ils ont passé des années à travailler à la conception d'une spécification qui ne serait jamais mises en œuvre.
.jpg)
Raymond Chen' s Livre intitulé identique (Addison-Wesley, 2007), The Old New Thing et site Web traitent de Windows histoire, programmation Win32 et vol de voiture par inadvertance.