Développement de logiciels à travers le prisme de l'expérience Milgram "Soumission à l'autorité"

La semaine dernière, j'ai passé un temps décent à supprimer le code mort de notre base de code. J'aime supprimer le code. Quant à moi, si peu de choses apportent le même plaisir que de mettre de l'ordre dans le code. Oui, je l'aime tellement que je suis perplexe devant les ingénieurs qui laissent du code inutile dans l'application. Mais le week-end, j'ai entendu quelqu'un parler de l' expérience de Milgram «Soumission à l'autorité» ( ils ont également écrit à ce sujet sur le hub) - et je n'ai pas pu m'empêcher de faire un parallèle entre la personne qui a choqué un autre être humain et l'ingénieur qui laisse des bogues connus et un mauvais code.

Si vous n'êtes pas familier avec l'expérience de Stanley Milgram, cela consiste dans le fait que l'expérimentateur (une personne ayant autorité) ordonne au professeur (l'objet d'étude) de battre l'étudiant dans une série de décharges croissantes de courant, qui se trouve dans une autre pièce. Illustration Wikipédia:

E - expérimentateur, T - enseignant, L - apprenant

L'essence de l'expérience était d'étudier les réactions des gens aux ordres qui entrent en conflit avec leurs principes moraux. Avant l'expérience, on pensait que la plupart des sujets arrêteraient l'expérience dès qu'ils se rendraient compte qu'ils blessaient l'étudiant. Cependant, au cours de l'expérience, il s'est avéré qu'un nombre frappant de sujets ont atteint une décharge maximale de 450 volts.

Dans la première série d'expériences de Milgram, 65% des participants (26 personnes sur 40) ont utilisé la valeur maximale possible de 450 volts, bien que ce ne soit pas agréable pour eux de le faire; à un certain moment, chaque participant s'est arrêté et a douté de l'expérience; certains participants voulaient arrêter et rendre l'argent qu'ils avaient payé pour leur participation. Au cours de l'expérience, les participants ont éprouvé divers degrés d'excitation et de stress. Ils transpiraient, tremblaient, bégayaient, se mordaient les lèvres, gémissaient, enfonçaient leurs ongles dans la peau, certains riaient nerveusement.

Lorsque nous apprenons de tels résultats, nous voulons croire que nous ne ferons jamais cela. Nous voulons croire que «simplement obéir aux ordres» est un défaut humain que nous n'avons pas. Mais des expériences comme celle de Milgram montrent qu’une telle foi est au mieux optimiste et au pire complètement fausse.

Et maintenant que nous savons comment les gens réagissent à l'autorité, lorsque la douleur physique est en jeu, voyons comment les programmeurs réagissent à l'autorité lorsqu'il s'agit de choses plus abstraites, telles que la frustration et les désagréments. Prenons le diagramme de l'expérience de Milham et remodelons-le pour refléter l'équipe de développement:

Si nous regardons l'équipe de développement comme indiqué dans l'illustration, il n'est pas si surprenant que nous, ingénieurs, laissions un mauvais code et des bogues connus. Probablement, à un moment donné, la personne au pouvoir a clairement indiqué que nous n’avons pas le temps de résoudre les problèmes ou que ces problèmes n’ont pas la priorité par rapport à d’autres éléments de la feuille de route. Ou que la suppression du code mort n'apporte pas de valeur à l'utilisateur. En conséquence, nous laissons le code tel quel et passons à la tâche suivante, bien que cela entre en conflit avec notre boussole morale et les concepts de ce qui est bon et de ce qui est mauvais.

Dans l'expérience de Milgram, les sujets hésitaient souvent et protestaient contre l'envoi d'une nouvelle décharge à une personne dans une autre pièce. Dans de tels cas, l'expérimentateur a exigé la continuation d'une des phrases prédéfinies:

• «Veuillez continuer» (Veuillez continuer / Veuillez continuer);
• «L'expérience exige que vous continuiez»;
• «Il est absolument essentiel que vous continuiez» (Il est absolument essentiel que vous continuiez);
• "Vous n'avez pas d'autre choix, vous devez continuer".

En n'utilisant que des mots, l'expérimentateur a pu s'assurer que 65% des sujets contre leur volonté battaient d'autres personnes avec des décharges de courant très douloureuses. Je me demande quels mots nous utilisons dans le contexte du développement logiciel?

• Ce n'est pas ce que nous décidons, mais l'équipe produit
• Nous devons respecter la date limite
• L'équipe marketing est sur le point de publier un communiqué de presse la semaine prochaine.
• Nous fermons trop peu de billets
• Nous allons tout de même jeter ce code
• Ceci est une solution temporaire.
• Besoin d'améliorer les performances de votre équipe
• Cela affectera un petit nombre d'utilisateurs.
• Ce n'est pas une priorité pour nous maintenant.
• Nous le réparerons plus tard
• C'est ce que veut la direction
• Pourquoi si longtemps?
• Besoin de le faire plus rapidement.

Je n'écris pas à ce sujet afin de suggérer une solution. Je ne l'ai pas. J'écris pour cultiver - d'abord en moi-même - la sympathie et la compréhension . Quand je vois un code qui laisse un sentiment de perplexité ou de comportement que je ne comprends pas, je dois me rappeler que les actions ne reflètent pas toujours les intentions. Je dois me rappeler que les ingénieurs ne laissent pas de mauvais code non pas parce qu’ils n’en ont rien à faire - ils laissent du mauvais code parce qu’ils n’ont pas eu la liberté de le mettre en ordre. Et ils laissent des bogues non pas parce qu'ils ne se soucient pas des utilisateurs, mais parce qu'ils n'ont pas le pouvoir de s'écarter de la feuille de route du produit.