Culte du Cargo et développement informatique

« on a toujours fait comme ça » (la pire des réponses, surtout en informatique)

Quelque chose qu’on appelle dans certaines situations « normalisation de la déviance ». Deux super lectures à ce sujet, une principalement à propos d’informatique : https://danluu.com/wat/ ¹, une nettement plus longue et dont le lien avec le sujet ne me revient pas précisément (je l’ai classé comme ça mais je saurais plus dire si c’est parce qu’il est devenu normal de pas savoir piloter en manuel, ou normal de pas piger les indicateurs électroniques, ou autre²) mais qui parle d’aviation : http://www.vanityfair.fr/actualites/international/articles/vol-af-447-rio-paris-reconstitution-des-minutes-qui-ont-precede-le-crash/23618

Moi qui pensais me coucher tôt, j’ai passé des plombes à lire ces articles passionnants. Du coup je ne sais pas trop si je dois te remercier ou t’insulter.

Dans le doute, merci.

Mon plaisir, ce sont des "traits" intéressants de notre champ professionnel.

Je pense qu’on cargo culte tous, pas forcément tous à grande échelle, mais on le fait tous. Je pense plus particulièrement à ce qui est config et tooling quand on est développeur. Si t’es développeur et que tu cargo culte dans ton code, que ce soit des "feintes" ou des patterns, pas bien. Pas de ça dont je parle.

Exemple : Quand je traine dans les dotfiles de quelqu’un d’autre et que je prends un bout de config zsh, vim, weechat, souvent je ne comprends pas exactement le bout de script que je prends, donc j’isole pas parfaitement la partie qui m’intéresse. Ça pose parfois problème plus tard.

Peut-être que tenter d’isoler les choses est justement un bon moyen d’éviter de cargo culter ?

Je pense qu’on a tous à un moment ou un autre utilisé des incantations magiques. Copier-coller des bouts de Makefile qui contiennent des target PHONY et des lignes qui commencent par - ? Assembler des bouts de bash sans savoir précisément qu’est-ce qui fait quoi ?

1
2
3
4

#!/usr/bin/env bash
set -euo pipefail

. foo.sh

Je crois qu’à l’époque où je copiais des bouts de DHTML pour mettre de la neige sur ma page perso lycos.fr, quand ça marchait pas j’enlevais tout ce que je pigeais pas, puis y’a rien qui marchait, puis je rajoutais petit à petit ce que j’avais enlevé ce qui me permettait de reverse engineerer l’effet de chaque ligne. Je pense que c’est en partie comme ça que j’ai appris à programmer et que c’est pas con bien qu’inefficace ?

En tout cas c’est une bonne idée d’exposer les gens à des "phénomènes" certainement connus mais pour lesquels ils ne savent pas forcément qu’on a un nom.

Après il me semble illusoire de vouloir une compréhension profonde de tout ce qui nous entoure. Même dans nos développements logiciels.

Je veux dire, je code régulièrement dans le noyau Linux qui est un monstre de complexité si on souhaite comprendre en détail son fonctionnement. Et je pense que seuls quelques personnes dans le monde en ont une compréhension profonde et globale.

C’est le concept d’encapsulation qui est au cœur de l’automatisation. On délègue de nombreuses tâches complexes qu’on ne comprend pas et on espère que les entrées / sorties que l’on a apprise (via la documentation ou une formation) suffise. Mais parfois non, des détails internes non réellement exposés restent utiles mais sont souvent cachés voire difficile à assimiler. Du coup, paf, tu es bloqué dès que tu sors un peu du cadre prévu initial sans que tu puisses t’en rendre compte.

Dans le cas des avions de lignes, il est je pense douteux de croire qu’un pilote peut avoir aujourd’hui une maîtrise complète de l’appareil, surtout quand il sort des sentiers battus. Il faut les former pour qu’ils en aient une connaissance suffisante pour la plupart des cas mais c’est tout.

Ce qui est étonnant, c’est que les pilotes (dans le cadre du vol documenté plus haut) étaient isolés. Pas de contacts avec des gens au sol avec potentiellement un référent technique et des ingénieurs du constructeur pour les aider. Technologiquement cela me semble possible et cela pourrait permettre de compenser le manque de compréhension des pilotes dans certains cas.

Je crois qu’à l’époque où je copiais des bouts de DHTML pour mettre de la neige sur ma page perso lycos.fr, quand ça marchait pas j’enlevais tout ce que je pigeais pas, puis y’a rien qui marchait, puis je rajoutais petit à petit ce que j’avais enlevé ce qui me permettait de reverse engineerer l’effet de chaque ligne. Je pense que c’est en partie comme ça que j’ai appris à programmer et que c’est pas con bien qu’inefficace ?

J’ai souvent fait ça aussi. C’est terriblement inefficace, mais très formateur. J’imagine donc qu’il ne faut pas tout le temps appliquer cette méthode, mais de temps en temps c’est utile.

Après il me semble illusoire de vouloir une compréhension profonde de tout ce qui nous entoure. Même dans nos développements logiciels.

C’est clair. En fait, dans nos boulots, il y a un niveau de compréhension de ce qu’on fait : le but du jeu, c’est de réussir à comprendre suffisamment ce qu’on fait pour éviter d’y aller par magie et hypothèses théoriques, mais de garder un niveau d’abstraction assez élevé pour éviter de perdre du temps et de l’énergie à maîtriser des détails inutiles.

Donc, on se retrouve en permanence à devoir évaluer si on comprends assez bien ce qui se passe pour éviter de faire des conneries ; et à devoir évaluer si on a besoin de creuser tel ou tel point. Sachant que tout ça c’est des fonctions à hypothèses et risques : le seul moyen de savoir si on avais vraiment besoin de comprendre un sous-système… c’est de le comprendre. Donc on doit faire des hypothèses, et prendre le risque de se planter – et la question n’est pas de savoir si on va se planter mais quand.

De mon point de vue, le problème apparaît dans deux cas :

1. La fonction d’évaluation du risque est clairement foireuse (donc, soit on fait plein de trucs magiques, soit on perds un temps énorme sur des détails).
2. Les gens qui refusent de se poser la question : « est-ce que je comprends ce que je fais, et est-ce que j’ai besoin de mieux le comprendre ? »

C’est un peu décousu, mais il y aurait de quoi faire plusieurs articles sur le sujet.

Un autre cas de cargo culting qu’on n’a pas encore évoqué il me semble c’est la perpétuation de vieux mythes.

J’avais une histoire en tête à base de toast dont quelqu’un coupait les bords avant de toaster mais je l’ai pas retrouvée, après beaucoup de recherche j’en ai trouvé des variantes et découvert que c’est une ~vieille fable/blague/anecdote. Voici une traduction d’une version trouvée ici, il y en a plusieurs à cette adresse :

La jeune mariée cuisine pour la première fois un repas pour son mari et s’essaie à la fameuse recette de rôti de sa mère, coupant les deux extrémités du rôti comme sa mère l’a toujours fait. Le mari trouve le rôté délicieux mais demande "Pourquoi est-ce que tu as coupé les deux bouts du rôti ? C’est le meilleur !" Elle répond : "Ma mère a toujours préparé le rôti comme ça".

La semaine suivante, ils se rendent chez sa grand-mère, et elle prépare le fameux rôti, coupant à nouveau les deux extrémités. La jeune mariée, certaine de passer à côté d’un détail crucial, demande à sa grand-mère pourquoi elle enlève les deux bouts. La grand-mère lui répond : "Ma chérie, c’est le seul moyen pour qu’il entre dans le plat !".

Pour illustrer le rapport avec l’informatique, j’ai vu des gens ici sur les forums expliquer qu’il fallait toujours faire :

1
2

const l = xs.length
for (let i = 0; i < l; i++) {

au lieu de :

1

for (let i = 0; i < xs.length; i++) {

parce que comme ça, la condition i < xs.length ne calculerait pas xs.length à chaque itération de la boucle.

C’était peut-être vrai il y a 10 ans, mais de nos jours c’est un conseil aussi avisé que s’entourer de cactus pour bloquer les ondes électromagnétiques.

Pas facile de convaincre les gens que ce qu’ils ont appris n’est plus valable, d’autant plus quand ils ne sont pas capables de vérifier par eux-mêmes parce que vérifier ça n’est pas possible avec leurs outils habituels.

Perso, je vois des occurrences de ce biais régulièrement dans mon équipe, appliqués le plus souvent par manque d’expérience face à certaines problématiques. Pour y faire face en tant que tech lead, j’ai adopté une stratégie dans laquelle j’accepte de perdre un peu de temps et d’efficacité en laissant les gens se planter et en rattrapant le truc avant qu’il ne soit trop tard, pour qu’ils comprennent leur erreur et ne la reproduisent plus sur le long terme.

Dernier exemple que j’aie en tête : on avait il y a pas très longtemps une tâche où l’on avait besoin de générer une sortie en HTML, mais dans un format hyper linéaire. Le collègue qui a pris la tâche est parti en disant "on va utiliser jinja2 !". En soi, ce n’est pas déconnant, puisque jinja2 est le moteur de template en Python, mais je pressentais que la solution n’était pas si automatique que cela, et qu’une bête concaténation de chaînes serait à la fois plus simple et plus efficace dans ce cas précis.

Au lieu d’en discuter pendant des plombes, parce qu’il n’est jamais évident de justifier de réinventer la roue (surtout auprès d’un dev Python), j’ai préféré dire : "ok, moi je le ferais pas comme ça et je me contenterais d’un ''.join(...), mais utilise jinja si tu le sens, tant que ton code est clair et que ça marche, ça me va".

Une demi-journée plus tard, mon collègue est revenu me voir : "bon, en fait, ça complique pas mal le code de faire rentrer mes données dans un moteur de templates". C’est là que je lui ai re-proposé ma solution. Je sais que dorénavant ce collègue ne fera plus automatiquement l’association "génération de HTML <-> moteur de templates". On y a perdu une demi-journée (ce qui est peanuts, objectivement), mais la leçon a été acquise.

En ce qui me concerne, j’estime que ce petit sacrifice, qui prend quand même du temps, vaut largement le coup par rapport aux alternatives (par exemple, imposer la solution, même en l’expliquant).

Merci beaucoup pour l’article, très intéressant, et les remarques associées.

Je pense qu’on a tous des exemples de cargo culting dans notre quotidien professionnel.

Je rajouterais une information / un lien à établir : le lien entre cargo culting et dette technique.

Ca n’est pas explicitement relié dans ton article, et pourtant il faut l’expliciter : le cargo culting est un ajout direct (et énorme) de dette technique dans un projet.

Quand on parle de dette, on parle de tous ces petits (ou pas) problèmes qui nous empêchent d’avancer au rythme où on aimerait. On dit souvent que pour implémenter une nouvelle fonctionnalité, ouvrir un service à l’extérieur etc. on doit "payer la dette". Et là-dedans, le cargo culting joue un rôle majeur : s’il est nécessaire d’implémenter une nouvelle fonctionnalité sur base de l’existant, qui fonctionne de façon un peu magique (une conf qui traîne, des "magic numbers" ça et là, etc.) il y a de fortes chances que la dette à payer s’en voit fortement augmenter. Cf. le "mais ça marchait bien jusque là, pourquoi ça fonctionne moins bien maintenant".

C’est d’autant plus problématique que c’est de la dette quasiment impossible à mesurer. Autant certains outils d’analyse peuvent remonter des problèmes engendrant de la dette technique (Sonar pour pas le citer) : code difficile à appréhender, refactoring nécessaire, bugs identifiés (file handlers jamais fermés), etc. autant ce type de problème n’est pas remonté. C’est ce que j’appelle de la "dette cachée" ou "dette latente" et elle est d’autant plus difficile à expliquer. "Mais pourquoi ça a pris 10 jours à implémenter ??" "Parce qu’on a mis les mains dans un truc incompréhensible et on a failli tout casser".

Y’a souvent une forme de mysticisme derrière tout ça, et le terme "culte" colle vraiment bien au problème. Le fait d’en être conscient, d’en parler, et de mettre un mot derrière ça est sans doute une bonne première étape. Pas suffisante, mais vraiment nécessaire.

Merci pour ça.