Génie logiciel Cargo Cult

Dans les mers du Sud, il existe un culte cargo des personnes. Pendant la guerre, ils ont vu des avions avec beaucoup de bons matériaux, et ils veulent que la même chose se produise maintenant. Ils se sont donc arrangés pour faire des choses comme des pistes, pour mettre des feux sur les côtés des pistes, pour faire une cabane en bois pour qu’un homme puisse s’asseoir, avec deux morceaux de bois sur la tête pour les écouteurs et des barres de bambou qui sortent comme des antennes — c’est lui le contrôleur — et ils attendent que les avions atterrissent. Ils font tout bien. La forme est parfaite. Il ressemble exactement à ce qu’il avait l’air avant. Mais ça ne marche pas. Aucun avion n’atterrit. Donc j’appelle ces choses la science du culte de la cargaison, parce qu’elles suivent tous les préceptes apparents et les formes d’investigation scientifique, mais il leur manque quelque chose d’essentiel, parce que les avions n’atterrissent pas.
— Richard Feynman

Je trouve utile de faire un contraste entre deux styles de développement organisationnel différents: le développement “orienté processus” et le développement “orienté engagement”. Le développement axé sur les processus atteint son efficacité grâce à une planification habile, à l’utilisation de processus soigneusement définis, à une utilisation efficace du temps disponible et à une application habile des meilleures pratiques du génie logiciel. Ce style de développement réussit car l’organisation qui l’utilise s’améliore constamment. Même si ses premières tentatives sont inefficaces, une attention constante au processus signifie que chaque tentative successive fonctionnera mieux que la tentative précédente.

Le développement axé sur l’engagement porte plusieurs noms, dont “développement axé sur les héros” et “autonomisation individuelle.”Les organisations axées sur l’engagement se caractérisent par l’embauche des meilleures personnes possibles, leur demandant un engagement total dans leurs projets, leur donnant une autonomie presque totale, les motivant à un degré extrême, puis en voyant qu’elles travaillent 60, 80 ou 100 heures par semaine jusqu’à la fin du projet. Le développement axé sur l’engagement tire sa puissance de son énorme capacité de motivation – étude après étude a révélé que la motivation individuelle est de loin le plus grand contributeur à la productivité. Les développeurs prennent des engagements volontaires et personnels envers les projets sur lesquels ils travaillent, et ils font souvent des efforts extraordinaires pour que leurs projets réussissent.

Imposteurs organisationnels

Lorsqu’ils sont utilisés en connaissance de cause, les deux styles de développement peuvent produire des logiciels de haute qualité de manière économique et rapide. Mais les deux styles de développement ont des sosies pathologiques qui ne fonctionnent pas aussi bien, et qui peuvent être difficiles à distinguer des articles authentiques.

L’organisation imposteur de processus fonde ses pratiques sur une dévotion servile au processus pour le bien du processus. Ces organisations examinent des organisations axées sur les processus telles que le Laboratoire de génie logiciel de la NASA et l’ancienne Division fédérale des systèmes d’IBM. Ils observent que ces organisations produisent beaucoup de documents et tiennent des réunions fréquentes. Ils concluent que s’ils produisent un nombre équivalent de documents et tiennent un nombre comparable de réunions, ils réussiront de la même manière. S’ils génèrent plus de documentation et organisent plus de réunions, ils auront encore plus de succès! Mais ils ne comprennent pas que la documentation et les réunions ne sont pas responsables du succès; ce sont les effets secondaires de quelques processus efficaces spécifiques. Nous appelons ces organisations bureaucratiques parce qu’elles placent la forme des processus logiciels au-dessus du fond. Leur utilisation abusive du processus est démotivante, ce qui nuit à la productivité. Et ils ne sont pas très agréables à travailler.

L’organisation commitment-imposteur se concentre principalement sur la motivation des gens à travailler de longues heures. Ces organisations examinent des entreprises prospères comme Microsoft; observent qu’elles génèrent très peu de documentation; offrent des options d’achat d’actions à leurs employés; et ensuite les obliger à faire des montagnes d’heures supplémentaires. Ils concluent que s’ils minimisent eux aussi la documentation, offrent des options d’achat d’actions et nécessitent de nombreuses heures supplémentaires, ils réussiront. Moins il y a de documentation et plus il y a d’heures supplémentaires, mieux c’est! Mais ces organisations ne tiennent pas compte du fait que Microsoft et d’autres entreprises axées sur l’engagement ne nécessitent pas d’heures supplémentaires. Ils embauchent des gens qui aiment créer des logiciels. Ils associent ces personnes à d’autres personnes qui aiment créer des logiciels tout autant qu’elles le font. Ils fournissent un soutien organisationnel somptueux et des récompenses pour la création de logiciels. Et puis ils les relâchent. Le résultat naturel est que les développeurs et les gestionnaires de logiciels choisissent de travailler de longues heures volontairement. Les organisations imposteuses confondent l’effet (longues heures) avec la cause (motivation élevée). Nous appelons les organisations imposteuses des ateliers clandestins parce qu’elles mettent l’accent sur le travail acharné plutôt que sur le travail intelligent, et qu’elles ont tendance à être chaotiques et inefficaces. Ils ne sont pas très agréables à travailler non plus.

Génie logiciel Cargo Cult

À première vue, ces deux types d’organisations imposteuses semblent être exactement opposés. L’un est incroyablement bureaucratique, et l’autre est incroyablement chaotique. Mais une similitude clé est en fait plus importante que leurs différences superficielles. Ni l’un ni l’autre n’est très efficace, et la raison en est qu’aucun ne comprend ce qui fait vraiment réussir ou échouer ses projets. Ils passent par les mouvements de ressembler à des organisations efficaces qui sont stylistiquement similaires. Mais sans vraiment comprendre pourquoi les pratiques fonctionnent, ils se contentent essentiellement de coller des morceaux de bambou dans leurs oreilles et espèrent que leurs projets atterriront en toute sécurité. Beaucoup de leurs projets finissent par s’écraser parce que ce ne sont que deux variétés différentes d’ingénierie logicielle culte du fret, similaires dans leur manque de compréhension de ce qui fait fonctionner les projets logiciels.

L’ingénierie logicielle Cargo cult est facile à identifier. Les ingénieurs logiciels de Cargo cult justifient leurs pratiques en disant: “Nous l’avons toujours fait de cette façon dans le passé” ou “les normes de notre entreprise nous obligent à le faire de cette façon” — même lorsque ces méthodes n’ont aucun sens. Ils refusent de reconnaître les compromis impliqués dans un développement axé sur les processus ou sur les engagements. Les deux ont des forces et des faiblesses. Lorsqu’ils sont présentés avec de nouvelles pratiques plus efficaces, les ingénieurs logiciels de cargo cult préfèrent rester dans leurs cabanes en bois aux habitudes de travail familières, confortables et pas nécessairement efficaces. “Faire la même chose encore et encore et attendre des résultats différents est un signe de folie”, dit le vieil adage. C’est aussi un signe d’ingénierie logicielle culte du fret.

Le vrai débat

Dans ce magazine et dans de nombreuses autres publications, nous passons notre temps à débattre de la question de savoir si le processus est bon ou si l’autonomisation individuelle (en d’autres termes, un développement axé sur l’engagement) pourrait être meilleure. C’est une fausse dichotomie. Le processus est bon, tout comme l’autonomisation individuelle. Les deux peuvent exister côte à côte. Les organisations orientées processus peuvent demander un engagement extrême sur des projets spécifiques. Les organisations axées sur l’engagement peuvent utiliser habilement les pratiques d’ingénierie logicielle.

La différence entre ces deux approches se résume vraiment à des différences de style et de personnalité. J’ai travaillé sur plusieurs projets de chaque style, et j’ai aimé des choses différentes sur chaque style. Certains développeurs aiment travailler méthodiquement sur un calendrier de 8 à 5, ce qui est plus courant dans les entreprises axées sur les processus. D’autres développeurs apprécient la concentration et l’excitation qui accompagnent un engagement 24 ×7 dans un projet. Les projets axés sur l’engagement sont en moyenne plus excitants, mais un projet axé sur les processus peut l’être tout autant lorsqu’il a une mission bien définie et inspirante. Les organisations axées sur les processus semblent moins souvent dégénérer en sosies pathologiques que les organisations axées sur l’engagement, mais l’un ou l’autre style peut bien fonctionner s’il est habilement planifié et exécuté.

Le fait que les projets axés sur les processus et les engagements aient des sosies pathologiques a brouillé le débat. Certains projets menés dans chaque style réussissent et d’autres échouent. Cela permet à un défenseur du processus de souligner le succès du processus et les échecs de l’engagement et d’affirmer que le processus est la clé du succès. Cela permet au défenseur de l’engagement de faire la même chose.

La question qui est tombée au bord du chemin alors que nous débattons du processus par rapport à l’engagement est si flagrante que, comme la lettre d’Edgar Allen Poe, elle était peut-être si évidente que nous l’avons négligée. Nous ne devrions pas débattre du processus par rapport à l’engagement; nous devrions débattre de la compétence par rapport à l’incompétence. La vraie différence n’est pas le style choisi, mais l’éducation, la formation et la compréhension qui sont apportées au projet. Plutôt que de débattre du processus par rapport à l’engagement, nous devrions chercher des moyens d’élever le niveau moyen de compétence des développeurs et des gestionnaires. Cela améliorera nos chances de succès quel que soit le style de développement que nous choisirons.