The Windows Shutdown crapfest, french translation

Remember the article about the many ways of shutting down Windows Vista?
There was an answer from one of the guys working on this particular feature.
Once again, I wanted to provide a french translation. It’s pretty interesting😉
Sorry for those coming to read “funny stuff”, this post is rather serious, but I find it really super-interesting and its updates emphasize really well the open-mindedness of the author.


Vous vous souvenez de l’article sur les différentes façons d’éteindre Windows Vista?
Il y a eu une réponse d’un de ceux qui ont travaillé sur cette fonctionnalité en particulier.
Une fois de plus, j’ai voulu fournir une traduction en français. C’est plutôt intéressant😉
Désolé pour ceux qui viennent lire du “rigolo”, cet article est plutôt sérieux, mais je le trouve vraiment super-instructif, et ses modifications montre bien l’ouverture d’esprit de l’auteur.

Vendredi 24 Novembre 2006

Cacarnaval de l’Arrêt de Windows

Mise à jour : cet article à attiré pas mal l’attention. J’aimerais dire de suite que je suis désolé qu’il en ait attiré tout court; si j’avais à le refaire je n’aurais pas publié ça. Ci-dessous je décris un scénario très spécifique qui ne s’applique pas à Vista dans son ensemble; Je crois en fait que Vista va être plutôt impressionnant. Je suis vraiment désolé si j’ai offensé certain de mes anciens collègues ou d’autres Microsoftiens. J’espère que cet article peut être vu dans l’optique de “apprendre de mes erreurs — organisationnelles et personelles” plutôt qu’une attaque contre Microsoft. Un des commentaires dit quelque chose du genre, “c’est bien de vous voir écrire votre auto-évaluation” — c’est comme ça que j’espère que les gens interprèteront la chose.Et finalement, j’espère qu’il est évident que tout ce que je dis sur ce blog est mon opinion personnelle et n’a rien à voir avec mon employeur.

Merci-

-Moishe

J’ai travaillé chez Microsoft environ 7 ans, de 1994 à 1998, et de 2002 à 2006.

L’année la plus frustrante de ces sept était l’année que j’ai passée à travailler sur Windows Vista, qui s’appelait Longhorn à l’époque. J’ai passé une année entière à travailler sur une fonctionnalité qui aurait dû être spécifiée, codée et testée en une semaine. À mon heureuse surprise (où “heureuse” correspond au freude dans schadenfreude), Joel Spolsky a écrit un article sur ma fonctionnalité.

J’aimerais essayer d’expliquer comment celà a pu arriver.

J’ai travaillé dans l’équipe “Ergonomie Utilisateur Windows Mobile PC”. Cette équipe faisait partie de Longhorn d’un point de vue fonctionnalité mais faisait partie du group Tablet PC d’un point de vue hiérarchique. Pour trouver un responsable commun aux gens avec qui j’avais besoin de travailler, il fallait monter 6 ou 7 niveaux hiérarchiques sur l’organigramme, depuis ma position.

La raison d’être de mon équipe était : améliorer l’ergonomie pour les utilisateurs de PCs portables et ultra-portables. Bonne raison. Bien sûr l’équipe Shell Windows, dont j’avais besoin du code pour pour effectuer ma petite contribution, avait un planning à eux qui pouvait, ou non, se croiser avec le notre.

Mon équipe avait un Graphiste IHM très talentueux, et ma fonctionnalité en particulier avait un bon et persévérant responsable de programme, avec des idées bien arrêtées sur l’ergonomie utilisateur. Nous avions un Mac [propriété personnelle d’un membre de l’équipe] que nous regardions comme un canon d’une interface propre. Bien sûr l’équipe Shell avait aussi de supers Graphistes IHM et de nombreux bons et perséverants responsables de programme qui prônaient (je ne peux que le supposer) la simplicité et ainsi de suite. Peut-être qu’ils avaient un Mac aussi.

En plus de notre excellent graphiste IHM et du reponsable de programme bon et persévérant, nous avions un expert assistance-utilisateur, une équipe de testeurs, quelques couches de management, et moi, qui écrivais du code.

Donc juste dans mon équipe, voilà les gens qui venaient à chaque réunion du planning liée à cette fonctionnalité :

  • 1 program manager
  • 1 développeur
  • 1 chef du développement
  • 2 testeurs
  • 1 chef des tests
  • 1 graphiste IHM
  • 1 expert en ergonomie utilisateur
  • 8 personnes au total
Ces réunions de planning avaient lieu chaque semaine, pour toute l’année où j’ai travaillé sur Windows.En plus de tout ça, nous avions des dépendances dnas l’équipe shell (les gens qui ont écrit, spécifié et testé le reste du menu Démarrer), et dans l’équipe noyau (qui promettait de livrer la fonctionnalité pour faire de notre interface d’arrêt aussi simple et propre que nous le voulions). La part adéquate de l’équipe shell était d’à peu près la même taille que notre équipe, comme l’était la part adéquate de l’équipe noyau.

Donc ça nous fait une estimation — pour sortir un chiffre — de 24 personnes impliquées dans la fonctionnalité. De même chaque équipe était séparée des responsables par 6 niveaux hiérarchiques, donc rajoutons-les, ce qui nous fait 24 + (6 * 3) + 1 (le manager commun) 43 personnes au total avec un mot à dire dans la fonctionnalité. 24 d’entre eux étaient liées de manière assez proche du code, et sur ces vingt-quatre il y en avait exactement zéro avec un pouvoir de décision sur comment la fonctionnalité marchait. Quelque part dans les 19 restants, il y avait quelqu’un qui avait le mot de la fin, mais qui était-ce je n’en avais aucune idée puisque quand je suis parti de l’équipe — après un an — il n’y avait toujours aucune décision sur comment exactement la fonctionnalité devrait marcher.

D’ailleurs “fonctionnalité” est un mot trop fort; une description plus adéquate serait “menu”. Vraiment. Au moment où j’ai quitté l’équipe, la quantité de code que j’avais écrite pour cette “fonctionnalité” était d’environ deux cents lignes, arrondi au supérieur. [edit: notez qu’il y a des tonnes d’autres fonctionnalités plus compliquées qui supportent ce menu, comme le panneau de contrôle, le travail supplémentaire sur le noyeu, etc., dont le code était gigantesque comparé au mien. Notez aussi que ces fonctionnalités n’étaient, de loin, pas la seule chose sur lesquelles ces gens travaillaient]

Mais voilà comme le processus de design fonctionnait : toutes les 4 semaines environ, à notre réunion hebdomadaire, notre PM disait : “l’équipe shell n’est pas d’accord avec le look/impression/fonctionnement” et/ou “l’équipe noyau a décidé d’inclure/ne pas inclure un peu de fonctionnalité qui nous permet/empêche de faire cette chose en particulier”. Et après lors de notre réunion hebdomadaire nous passions environ 90 minutes à discuter d’à quoi notre fonctionnalité — euh, menu — devrait ressembler basé sur cette information “nouvelle”. Ensuite, à notre réunion hebdomadaire suivante, nous passions 90 minutes de plus à se disputer sur le rendu, puis sur la réunion hebdomadaire suivante on recommencer, et à la réunion hebdomadaire suivante on se mettait d’accord sur quelque chose… juste à temps pour obtenir un nouveau morceau d’information manquante de la part de l’équipe shell ou noyau, et recommencer le processus à nouveau.

J’aimerais préciser comment le développement se fait réellement dans l’équipe Windows.

Dans les petits projets de développement, il y a un dépôt de source central. Les assemblages sont produits, en général quotidiennement, depuis ce dépôt central. Les Développeurs ajoutent leurs changement au dépôt central au fur et à mesure, donc la production quotidienne est un aperçu assez bon de l’état courant du produit.

Dans Windows, ce modèle déraille simplement parce qu’il y a bien trop de développeurs pour accéder à un dépôt central. Donc Windows a un arbre de dépôts : Les développeurs soumettent dans des noeuds, et régulièrement les changements dans les noeuds sont intégrés au niveau supérieur de la hiérarchie. Avec une périodicité différente, les changements sont intégrés dans l’arbre depuis la racine vers les noeuds. Dans Windows, le noeud sur lequel je travaillais était à 4 niveaux de la racine. La fréquence d’intégration se dégradait de manière exponentielle et imprévisible au fur et à mesure que j’approchais de la racine, donc au final il fallait entre 1 et 3 mois pour que mon code aille jusqu’au noeud racine, et quelques multiples de ça pour qu’il atteigne les autres nouds. Il faut remarquer aussi que le seul ancêtre commun entre mon équipe, l’équipe shell et l’équipe noyau était la racine.

Donc en plus des problèmes décisionnels susmentionnés, chaque équipe n’avait aucune idée de ce que l’autre équipe faisait vraiment à moins que ça n’ait été fait depuis des semaines

Le résultat final de tout ceci est ce qui a finalement été livré : Le plus petit dénominateur commun, la plus simple et la moins polémique des possibilités.

Je n’ai aucune idée de combien du reste de Vista a fini comme ceci. Je pense (en fait, j’espère) que mon équipe était un cas pathologique; malheureusement c’en est un qui est visible.

[un autre edit : jusqu’à présent je n’avais joué avec Vista que sur un VirtualPC; hier j’ai joué avec une installation complète et c’est vraiment très cool. Si un menu avec trop de choix, qui n’est accessible que par un chevron est son plus gros problème, alors ça va aller]

3 thoughts on “The Windows Shutdown crapfest, french translation

Insert nice comment here :) / Par ici les gentils commentaires :)

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s