Bus Number – le plugin GitHub que mes collègues m’ont dit de ne pas écrire

• Un développeur, après avoir vécu le cas où l’unique contributeur d’un code source générant du revenu a disparu à la suite d’un licenciement, a voulu créer sur GitHub Enterprise un plugin de truck factor pour repérer les personnes « qu’il ne faut surtout pas perdre »
• Ses collègues craignaient que cet indicateur tombe rapidement sous le coup de la loi de Goodhart et devienne un outil de gestion servant non pas à protéger les personnes clés, mais à repérer « celles qu’on peut licencier »
• Le dépôt Truck-Factor d’origine et ses données restaient utilisables, mais la date de collecte des données était inconnue et la procédure du README n’était plus directement reproductible, ce qui a nécessité des ajustements manuels
• Le recalcul consistait à cloner plusieurs dépôts GitHub avec gnu parallel, puis à exécuter du code Java ; pour le noyau Linux, le truck factor ressort à 12 sans filtre linguist, puis à 8 avec le filtre
• Le résultat est inférieur aux chiffres de l’article d’origine — 90 dans le preprint de 2015, 57 dans la publication finale — ce qui ne permet pas vraiment de conclure à une amélioration du bus factor du noyau Linux

---

Bus Factor et une idée de plugin risquée

• Le Bus Factor ou Truck Factor désigne le nombre minimal de membres d’une équipe qui devraient disparaître soudainement pour qu’un projet s’arrête faute de personnes connaissant suffisamment le sujet
• Le point de départ remonte à une vague de licenciements autour de 2015, au cours de laquelle l’unique contributeur à une partie du codebase qui rapportait de l’argent à l’entreprise a été licencié
• Après avoir pensé au Truck Number, l’idée a émergé d’en faire un plugin GitHub Enterprise calculant les personnes « qu’il ne faut pas licencier »
• Lorsqu’il a présenté ce plugin pendant 5 minutes lors d’un lightning talk un jeudi après-midi, ses collègues ont estimé que des managers pourraient s’en servir pour identifier « les personnes qu’on peut licencier »
• Le cœur de cette réaction tenait à la loi de Goodhart

Recherche existante sur le Truck Factor et tentative de reproduction

• L’étude d’origine calculait, sur plusieurs projets GitHub populaires, combien de personnes devaient disparaître pour que le projet s’arrête
• Le noyau Linux faisait partie des sujets étudiés
• Au début du texte, il est indiqué que le premier preprint affirmait qu’il fallait le départ de 80 personnes pour arrêter Linux ; plus loin, les chiffres sont récapitulés à 90 dans le preprint de 2015 et 57 dans la publication complète
• Avec mclare, l’auteur a tenté de reproduire les résultats près de 10 ans plus tard pour vérifier si le truck factor s’était amélioré
• Le dépôt GitHub des auteurs d’origine était toujours exploitable

Contraintes liées aux données et à l’environnement d’exécution

• Les données de l’article étaient fournies en JSON, et la visualisation d’origine reposait sur un CSV récupérable par scraping
• En revanche, il était impossible de connaître la date de collecte des données
• Les instructions du README ne fonctionnaient plus telles quelles, et il a fallu consulter les issues GitHub pour corriger la procédure d’exécution
• La liste complète des dépôts GitHub a été extraite de la première colonne du CSV d’origine, puis tous les dépôts ont été clonés
• Plusieurs commandes git clone ont été lancées en parallèle avec gnu parallel

gnu parallel, linguist et blocages sous NixOS

• Même avec -j 8 sur gnu parallel, les 32 cœurs du laptop semblaient tous utilisés
• On voyait bien 8 processus git clone en parallèle, mais de nombreux processus git index-pack consommaient tous les cœurs
• Une explication possible est que git index-pack, en tant que sous-processus forké, amenait parallel à lancer d’autres git clone
• Le code Truck Factor utilise linguist de GitHub pour exclure les fichiers de documentation
• Dans un environnement NixOS, faute d’expérience avec Ruby, l’auteur n’a pas réussi à résoudre à temps l’installation des Ruby Gems ; il demande donc une méthode pour installer le plugin linguist dans un flake Nix ou une pull request

Procédure réelle de recalcul

• Le dépôt d’origine a été forké puis cloné en local, et la méthode d’exécution a été ajustée en suivant le README
• Les sources Java ont été compilées en jar avec mvn package
• Un premier test a été fait sur le dépôt GitHub de numpy, avant de recalculer l’ensemble des dépôts
• mclare a téléchargé le CSV de la visualisation d’origine et converti sa première colonne en liste de dépôts GitHub
• Le flux d’exécution était le suivant
  • clonage des dépôts avec parallel -j 8 git clone ::: $(cat ../meta/repo_list.txt)
  • déplacement dans le répertoire gittruckfactor/scripts pour éviter une erreur awk
  • extraction des informations de commit git pour chaque dépôt avec commit_log_script.sh
  • traitement des données de commit extraites en exécutant gittruckfactor-1.0.jar
• Avec une connexion Internet domestique gigabit rapide, le clonage séquentiel de tous les dépôts a pris 17,5 minutes
• Le traitement de chaque dépôt semble lui aussi avoir pris environ 18 minutes

Résultats du recalcul sur le noyau Linux

• L’exemple de sortie pour le noyau Linux affichait TF = 12, coverage = 49.98%
• Parmi les TF authors figuraient Linus Torvalds, Mauro Carvalho Chehab, Rob Herring, Thomas Gleixner et Krzysztof Kozlowski
• Linus Torvalds apparaissait avec 5 712 fichiers et 6,59 %
• Sans le plugin linguist, donc sans filtrer la documentation ni les bibliothèques tierces, le truck factor du noyau Linux était de 12
• Après installation du plugin linguist par mclare sur son système, le truck factor du noyau Linux obtenu était de 8

Éléments absents du calcul et pistes à vérifier ensuite

• Ce calcul ne prend pas en compte le processus de review
• Or, plus un développeur progresse en carrière, plus il est censé faire de review plutôt que taper directement du code au clavier
• Les points à vérifier ensuite sont les suivants
  • si le calcul du truck factor prend en compte les en-têtes git co-authored-by et reviewer
  • si ce n’est pas le cas, s’il est possible de les intégrer au calcul
  • pourquoi la valeur Linux diffère autant 10 ans plus tard
  • si le fait de ne pas avoir appliqué une distance de Levenshtein de 1 pour fusionner les alias de développeurs, comme dans l’article d’origine, a influencé le résultat
  • si un checkout du dépôt du noyau Linux à la mi-2015 produit toujours 80 sur le même code
  • si, l’algorithme ayant été mis à jour en 2016, il est possible de recalculer des valeurs ultérieures
• Il est aussi possible de consulter les 156 citations de l’article d’origine pour voir s’il existe une meilleure méthode de calcul
• Des projets récents majeurs comme Rust n’étaient pas inclus dans l’article de 2015 ; on peut donc comparer les projets populaires actuels à leur historique passé
• On pourrait également créer un script trouvant le truck number année par année pour n’importe quel dépôt git

Un Bus Factor encore plus bas

• La question à vérifier était de savoir si le truck factor s’était amélioré avec le temps
• La réponse semble être non : il s’est plutôt dégradé
• Pour le noyau Linux, le résultat de cette exécution est nettement inférieur aux chiffres de l’article d’origine
• Selon que la documentation et les bibliothèques tierces sont filtrées ou non, le résultat pour le noyau Linux descend encore de 12 à 8
• Plus de visualisations et de détails sont disponibles dans l’article de mclare

[GN⁺]

Avis de Hacker News

• C’est précisément l’une des fonctionnalités de https://codescene.com/
  Elle repère les îlots de connaissance et les met en relation avec le code qui change fréquemment, afin d’identifier les hotspots risqués : beaucoup de changements, mais une faible diffusion des connaissances.
  Quand quelqu’un annonce son départ, on peut facilement voir le code que seule cette personne connaît, ce qui permet aussi de préparer plus facilement le plan de passation.
  Je n’ai jamais pensé que cela pouvait être détourné ; à l’origine, c’est un outil de visibilité. Un manager qui l’utiliserait de cette manière serait un mauvais manager, et s’il est déjà comme ça, cet outil ne changera rien.

  • Il ne faut pas voir l’« abus » de manière trop naïve. Imaginons que l’on appartienne au service de renseignement d’un pays. Disons qu’un pays appelé Tussie, interdit d’accès au grand noyau Kinux utilisé dans des équipements militaires du monde entier, découvre que la personne dans le bureau d’à côté a lancé un projet visant à forker ce noyau pour un usage interne national.
    Si l’on vise une promotion, on pourrait demander au service chargé du recrutement « 8 agentes ayant reçu une formation spéciale pour se rapprocher des nerds », ainsi que, en réserve, 8 doses de polonium au cas où cela échouerait.
    Cela peut sembler entièrement fictif, mais je sais qu’un CEO de startup licorne qui cherchait un seed round a réellement vécu quelque chose correspondant à la première partie.
  • J’ai connu trois entreprises où Pluralsight Flow a été déployé ; dans deux d’entre elles, les managers ont très vite commencé à utiliser les indicateurs pour le feedback, les évaluations de performance et les décisions d’embauche.
    Dans la troisième, les développeurs ont reconnu ce schéma de loin et ont refusé d’utiliser l’outil ou même d’être évalués avec.
    Ces outils coûtent absurdement cher, donc ceux qui les approuvent doivent forcément en tirer un retour sur investissement. Comme il n’existe pas de bonne façon de mesurer la productivité, les livrables ou les silos de connaissance, on finit par des remarques du genre « Jose a fait peu de PR cette semaine ».
  • L’usage de visibilité est excellent en soi, mais seulement tant qu’il peut rester dans ce cadre.
    Le problème, c’est que les développeurs peuvent aussi le voir et chercher à se placer sur des projets ou composants cibles pour entrer dans la liste des employés impossibles à licencier. Idéalement, les travailleurs pourraient se coordonner pour faire tomber le truck factor à 0, rendant le licenciement de quiconque difficile.
    Bien sûr, cela deviendrait alors une perte de temps presque totale, et confirmerait le point initial soulevé par les collègues du blogueur : « ça tombera immédiatement sous le coup de la loi de Goodhart ».
  • Un cabinet de conseil externe pourrait aussi s’en servir pour aider l’entreprise à procéder à des licenciements. Même si le manager est excellent.

• Chez Amazon, ce genre de chiffres est facilement accessible sous forme de rapports exécutables par n’importe quel manager dans le système de code, et il existe aussi beaucoup d’autres moyens de voir ce que fait une équipe et quels risques elle porte. Personnellement, je trouve cela utile.
  Le bus factor n’est qu’un angle de vue ; sous un autre angle, cela permet de repérer et corriger les silos, les ingénieurs qui ne collaborent pas avec les autres, ou les domaines où il est difficile de déplacer des ingénieurs.
  Certains développeurs craignent d’être remplaçables et pensent qu’un système qu’eux seuls connaissent constitue une sécurité de l’emploi, mais à l’inverse, c’est un risque technique et cela peut aussi empêcher un bon ingénieur de passer sur un projet plus important. C’est aussi une porte de sortie pour faire autre chose quand on en a assez d’un système que l’on déteste.

  • Je n’ai pas peur d’être remplaçable. Si un endroit ne veut pas de moi, je n’ai pas envie d’y être non plus.
    En revanche, l’idée de remplaçabilité crée beaucoup d’overhead et empêche d’utiliser les personnes talentueuses au maximum de leurs capacités. Parce qu’en réalité, elles ne sont pas remplaçables.
    Dans certains endroits, c’est nécessaire, mais dans d’autres, l’overhead de process devient un risque bien plus grand pour la réussite du projet que le bus factor.
  • Je connais un développeur à qui l’on a refusé une mobilité et une promotion parce qu’il n’était pas facile de le remplacer.
    Résultat : il est parti dans les 3 mois.
  • « Si vous ne pouvez pas être remplacé, vous ne pouvez pas être promu. »
  • Du point de vue d’un employé dont l’objectif principal n’est pas d’optimiser les profits de l’entreprise, considérer qu’un système que lui seul connaît est une forme de sécurité de l’emploi est aussi une stratégie réaliste.
  • Tout au long de ma carrière, j’ai essayé de me rendre, moi et les autres développeurs, aussi remplaçables que possible. Une grande partie du travail de numérisation consiste déjà en cela, et c’est aussi parce que les silos de connaissance sont pénibles à gérer.
    L’une des raisons pour lesquelles j’utilise beaucoup TypeScript côté backend est que cela réduit à un seul le nombre de langages qu’une petite équipe doit connaître. Ainsi, quand un développeur frontend part en vacances, il peut réellement déconnecter, et quelqu’un d’autre peut couvrir. Quand quelqu’un change d’entreprise, c’est moins douloureux.
    Cela n’a jamais été un problème, et je considère la remplaçabilité comme une partie d’un système sain. Après quelques années côté management, l’une des premières choses que l’on apprend est que « tout le monde est remplaçable, ce n’est qu’une question de coût ». Donc un niveau de connaissance trop élevé peut même se retourner contre vous, si la direction cherche à réduire ce risque. Les licenciements pour raisons économiques, en particulier, sont aussi assez aléatoires.
    Cela dit, je n’aurais pas envie de travailler dans un endroit qui utilise ce genre d’indicateurs ridicules. Plus on met de paperasse autour du bon travail, moins j’ai de chances de vouloir collaborer. Ce genre de choses pousse facilement les gens à jouer avec les indicateurs plutôt qu’à faire du bon travail, et crée une culture mauvaise pour la productivité comme pour la qualité.

• gnu parallel exécute bien, comme demandé, 8 opérations git clone en même temps, et chaque git clone lance à sa guise de nombreux threads index-pack
  Ici, définir temporairement pack.threads à 1 avec git config peut aider

  • C’est un problème de plus en plus courant. Les deux couches parallélisent toutes les deux à hauteur du nombre de CPU ou de cœurs, cherchent à utiliser toute la machine, et la couche interne finit par créer N² threads/processus
    Comme cela croît au carré, plus il y a de CPU, plus le problème s’aggrave. Avec 32 cœurs, cela fait 32² = 1024, et dans ce cas précis, comme Parallel était réglé sur 8, cela s’est probablement arrêté autour d’un maximum de 256 processus index-pack. Même ainsi, il faut beaucoup de mémoire pour encaisser cela, et en pratique il n’y a aucun bénéfice
    La solution consiste à ne paralléliser qu’une seule des deux couches
    À propos de pack.threads, man git-config dit ceci : indique le nombre de threads à créer lors de la recherche des meilleures correspondances de delta, et exige que git-pack-objects(1) ait été compilé avec pthreads. Sinon, l’option est ignorée avec un avertissement. C’est une option destinée à réduire le temps de packing sur les machines multiprocesseurs, mais la mémoire nécessaire à la fenêtre de recherche de delta est multipliée par le nombre de threads. Si l’on indique 0, Git détecte automatiquement le nombre de CPU et règle le nombre de threads en conséquence
  • Au lieu de le configurer temporairement avec git config, il suffit d’utiliser git -c pack.threads=1 clone : https://git-scm.com/docs/git#Documentation/git.txt--cltnameg...

• Cette interprétation n’est pas terrible. Je vois cet article comme un texte destiné à tous les responsables d’ingénierie
  Le bus factor désigne à quel point une équipe souffre si quelqu’un de l’équipe, ou soi-même, se fait renverser par un bus
  Le bus factor idéal pour chaque membre de l’équipe est 0. Au début, cela peut sonner comme « rendez tout le monde jetable », mais en réalité c’est presque l’inverse, et c’est précisément le point important
  Une équipe doit être suffisamment bonne pour être a) autonome et b) dépourvue de zones mystérieuses. Dans l’état idéal, tout le monde comprend comment tout fonctionne. Les nouvelles recrues doivent pouvoir commencer à produire de la valeur immédiatement, et les personnes qui partent doivent pouvoir être rassurées par le fait qu’il ne reste pas de territoire inconnu
  Une équipe idéale où tout le monde a un BF de 0 est souhaitable. Cela signifie que les membres sont remplaçables, et que si quelqu’un tombe malade, part en vacances, quitte réellement l’équipe ou est retiré, n’importe quel autre membre peut combler le vide
  Plus important encore, un BF de 0 est le reflet de la simplicité. Le logiciel, les pipelines de build, test et déploiement, la documentation et les dispositifs de support doivent tous être cohérents et homogènes. Cloisonner l’information dans certaines personnes est mauvais, et tout le monde doit pouvoir builder et déployer
  Un BF de 0 est un indicateur sain, mais il ne se mesure absolument pas au nombre d’e-mails, de commits, de PR, de lignes de code, à la vitesse de réponse ou aux heatmaps GitHub. Ces métriques ne montrent rien et sont au contraire nuisibles et épouvantables
  Évaluer les gens avec ce genre de métriques ne vaut pas mieux que des singes devant une machine à écrire. Davantage de startups devraient entendre ça

  • J’ai toujours entendu le bus factor dans le sens inverse. Du genre : « combien de personnes doivent se faire renverser par un bus pour que le projet ne puisse plus continuer ? », et je pensais que la valeur optimale était égale à la taille de l’équipe
    On semble parler du même concept, mais c’est surprenant de voir que ce nombre n’est pas toujours utilisé dans le même sens
  • J’ai travaillé sur un projet où, dans le monde entier, les personnes possédant une compétence donnée se comptaient sur les doigts d’une main. À ce moment-là, le bus factor était clairement de 1
    Dans les projets qui repoussent les limites du possible, la simplicité n’est parfois pas une option. Bien sûr, cela ne représente qu’une petite part de l’ensemble des projets logiciels, mais quand on fait quelque chose d’inédit, la préoccupation principale est moins de garder le code aussi simple que possible que de se demander « comment diable va-t-on réussir à faire ça ? »
    Cela ne veut pas dire qu’une faible qualité de code est acceptable. Simplement, quand on s’attaque à des choses difficiles, il arrive qu’un code complexe soit nécessaire, et ce n’est parfois qu’après plusieurs générations que des design patterns se stabilisent et permettent de réaliser cette chose difficile avec un code moins complexe. Cela peut être dix ans plus tard
  • Si, dès le premier jour, n’importe qui peut comprendre le code et qu’aucune connaissance métier n’est nécessaire, quelle est la proposition de valeur du produit ou de l’équipe ?
    Si la chose la plus complexe que l’on puisse construire est une application de todo list, je ne pense pas qu’on crée beaucoup de valeur pour la société
  • Les personnes qui font bien leur travail et ont confiance en elles cherchent activement à réduire leur propre bus factor
    Avoir un bus factor élevé signifie que votre employeur vous retient pour ce que vous avez fait par le passé, plutôt que pour votre potentiel futur
  • C’est comme ça que pense l’armée. Elle part du principe qu’elle doit continuer à fonctionner même si elle perd des gens

• L’argument central de l’article original est ce passage
  « Notre estimation repose sur une hypothèse de couverture. Si l’ensemble actuel des auteurs couvre moins de 50 % de l’ensemble actuel des fichiers du système, il est très probable que le système subisse de sérieux retards ou s’arrête »
  Ici, l’auteur d’un fichier est défini comme un utilisateur ayant apporté une contribution significative à ce fichier selon un poids précalculé

• D’un côté, je serais plutôt surpris que ce genre de métriques de dashboard ne soit pas déjà présent dans certains logiciels d’entreprise. Dans une ancienne boîte, la direction avait réellement demandé s’il était possible de produire un rapport quotidien indiquant qui, dans le département, envoyait et recevait le plus d’e-mails
  Je n’aimais pas la direction que cela risquait de prendre, donc j’ai refusé, mais un autre collègue l’a fait. Comme prévu, la personne qui recevait et envoyait le plus d’e-mails était l’administrateur système, parce que son compte était configuré comme expéditeur automatique pour plusieurs serveurs. Il s’envoyait à lui-même des centaines d’e-mails d’alerte par jour, auxquels s’ajoutaient les newsletters et e-mails récapitulatifs auxquels il était abonné
  D’un autre côté, si vos collègues vous ont tous demandé de ne pas faire quelque chose qui pourrait affecter leur emploi et que vous persistez à le faire comme projet perso, cela semble être un comportement assez méchant

  • En 2015, quand mes collègues m’ont demandé de ne pas le faire, je ne l’ai pas construit
    Je voulais simplement voir si les logiciels open source que j’utilise diffusent suffisamment bien les connaissances pour augmenter leurs chances de survie
    J’ai refusé de faire ce truc méchant
  • C’est une métrique absurde

• Je pense que « plus un développeur monte dans l’échelle de carrière, moins il doit taper lui-même au clavier et plus il doit faire de reviews » est un malentendu courant dans les entreprises tech
  On ne cherche pas à transformer un excellent développeur en manager médiocre

  • Exact. Il existe des tech leads excellents pour écrire du code, mais catastrophiques sur des compétences comme le leadership ou le feedback
    Il serait largement mieux comme développeur senior que comme tech lead. Il est difficile d’imaginer à quel point l’équipe souffrirait s’il devenait manager
  • Si vous considérez la revue de code comme du « management », c’est assez sérieusement préoccupant

• La triste ironie, dans cette affaire, c’est que la question reste mal posée
  Quand une startup doit procéder à des licenciements, la question n’est pas « qui peut-on licencier tout en maintenant l’activité existante ? », mais « quelle est l’équipe capable de construire assez vite la prochaine version du produit pour éviter de couler ? »
  Chaque bifurcation reste une bifurcation, et beaucoup d’entreprises sont mortes faute d’avoir choisi une voie assez rapidement

• CPAN suit depuis longtemps le bus factor. Par exemple, https://metacpan.org/pod/Moose affiche un Bus Factor de 5 dans la colonne d’informations à gauche

  • La méthode de calcul de ce chiffre est également documentée : https://www.olafalders.com/2021/06/30/cpan-bus-factor/

• Nous préférons appeler cela le facteur loto
  L’idée étant : le projet peut-il continuer si quelqu’un gagne au loto et part sur une île tropicale sans électricité ni réseau télécom ?
  Formulé ainsi, c’est moins sinistre

  • Le gagnant du loto donne son préavis deux semaines à l’avance et, si c’est vraiment nécessaire, on peut aussi l’appeler plus tard
    Quelqu’un percuté par un bus disparaît immédiatement. Ce n’est pas la même chose
  • Un bon employé voudra transmettre son projet et répondre aux questions, mais il faut aussi se préparer aux cas où ce ne serait pas possible
  • Présenter un changement d’emploi par euphémisme comme une sudden death laisse un arrière-goût désagréable
    Certaines personnes n’aiment pas non plus les métaphores sportives, mais je pense qu’elles valent au moins mieux que les métaphores militaires
    De toute façon, il arrive souvent qu’il n’y ait pas vraiment de passation, donc le caractère soudain n’est peut-être pas un facteur si important
  • Se faire renverser par un bus peut être l’option la plus facile, il faut donc aussi intégrer cette possibilité
  • Je ne connais personne qui ait gagné un gros jackpot ou se soit fait renverser par un bus, mais je connais plusieurs personnes qui ont quitté leur poste après être devenues riches grâce aux cryptomonnaies