Selon une étude, près de 10 % des ingénieurs logiciels « ne font pratiquement rien »
Le 27 novembre à 15h30
3 min
Économie
Économie
Sur son profil LinkedIn, Yegor Denisov-Blanch explique avoir abandonné l'école à l'âge de 14 ans, avant d'apprendre, en autodidacte, à coder en PHP, ce qui lui aurait permis de gagner 500 000 dollars à l'âge de 18 ans. Il aurait ensuite dépensé 250 000 dollars pour retourner à l'université, en sautant cinq classes, avant de devenir chef de cabinet du PDG de la région EMEA et transformation numérique/stratégique de DHL en 2017 puis, depuis 2022, chercheur à Stanford, où il étudie la productivité de l'ingénierie logicielle.
Dans un thread sur X.com, il explique disposer de données sur les performances de plus de 50 000 ingénieurs dans des centaines d'entreprises ayant accepté de partager leurs dépôts Git privés avec son équipe, et avance que « ~ 9,5 % des ingénieurs logiciels ne font pratiquement rien ». Ses conclusions (qui restent à confirmer) vont certainement faire parler et soulèvent en tout cas des questions, y compris sur la méthodologie.
Quoi qu’il en soit, son équipe travaille sur un modèle qui quantifie la productivité en analysant le code source de dépôts Git, et en simulant un panel de 10 experts évaluant chaque livraison à travers de multiples dimensions. Or, ils ont constaté que 14 % des ingénieurs logiciels travaillant à distance ne font presque pas de travail (et qu'ils qualifient dès lors d' « ingénieurs fantômes »), contre 9 % dans des rôles hybrides et 6 % au bureau.
« Bien qu'il s'agisse d'une méthode imparfaite pour mesurer la productivité », précise-t-il, ils ont aussi découvert que « ~58% des personnes interrogées effectuent moins de 3 commits/mois ».
Ils ont ensuite cherché à mesurer ce que cette absence de productivité coûterait à leurs employeurs respectifs, et estimé que les 17 100 « ingénieurs fantômes » d'IBM (soit 9,5 % de ses 180 000 ingénieurs) lui coûterait 2,5 milliards de dollars (sur la base d'un coût annuel de 150 000 dollars par ingénieur), les 10 450 de Microsoft 1,5 milliard, les 9 500 d'Oracle et Google 1,4 milliard.
« En supposant de manière prudente que seulement 6,5 % des ingénieurs dans le monde sont improductifs (au lieu de 9,5 %), cela représente 90 milliards de dollars effectivement gaspillés » par 1,8 million d'ingénieurs fantômes dans le monde entier, que Yegor Denisov-Blanch voudrait voir licenciés.
Ils proposent aux entreprises et organisations employant « idéalement » plus de 50 ingénieurs de participer à leur enquête en partageant avec eux leurs dépôts Git, ce qui permettrait aux employeurs d' « obtenir une visibilité granulaire sur les résultats de vos processus d'ingénierie », et de « réduire potentiellement les coûts », en identifiant leurs propres « ingénieurs fantômes ».
En réponse à des commentaires ironisant sur les « managers fantômes », le chercheur rétorque que « Quelque chose me dit que le chiffre est peut-être supérieur à 9,5 % ! », tout en précisant qu'ils ont aussi exclu les ingénieurs, par ailleurs managers, de leur base de données, ainsi que toute persone n'écrivant pas de code.
Il précise aussi que les commits ne leur servent pas de mesure de la productivité, et renvoie à un article de recherche publié en septembre dernier détaillant leur méthodologie, en vue de « Prédire les évaluations des experts dans les revues de code logiciel ».
Le 27 novembre à 15h30
Commentaires (36)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousAujourd'hui à 15h35
- quid de la méthodologie ?
- quid de la prise en compte de l'encadrement (un bouffe temps comme pas permis) ?
Modifié le 27/11/2024 à 19h04
Maintenant, git est peut-être aussi un peu la source du problème: Un peu pénible, conflits quasiment inévitables même sur des truc disjoints... Courant de passer beaucoup plus de temps à livrer qu'a avoir développé/testé ce qu'on livre. D'une manière générale j'ai essentiellement connu des système de gestion de conf centralisés avant git qui posaient certes des pb de réplication à leurs admins mais en comparaison très peu aux développeurs. Git a inversé l'affaire.
Aujourd'hui à 19h14
Et, même si ca n'a pas grand chose à voir avec le sujet, je suis en désaccord avec toi: "j'ai essentiellement connu des système de gestion de conf centralisés avant git qui posaient
certesdes pb de réplication à leurs adminsmais en comparaison très peuet autant aux développeurs. Git ainverséamélioré l'affaire" (pour moi). C'est très subjectif et dépendant du contexte.Pour en revenir au sujet, la métrique "nombre de commits" est très mauvaise, même si elle m'avantage personnellement, étant un grand "committer" de nature et n'aimant pas trop "squasher". Je bats tout le monde dans la boite. Je vais me servir de cet argument pour ma prochaine augmentation :)
Aujourd'hui à 15h37
Aujourd'hui à 15h46
Aujourd'hui à 15h57
Aujourd'hui à 16h51
Aujourd'hui à 17h54
Aujourd'hui à 15h53
Aujourd'hui à 15h54
Aujourd'hui à 16h00
Modifié le 27/11/2024 à 17h25
Aujourd'hui à 22h53
Aujourd'hui à 16h02
Un collègue à qui l'on reprochait justement de faire "pas assez de commit" (alors qu'il était excellent) a écrit un bot pour faire des commits inutiles assez régulièrement, et du coup il est remonté dans l'indicateur inutile. CQFD
Aujourd'hui à 16h11
--date
🙄Aujourd'hui à 19h24
Modifié le 27/11/2024 à 16h47
Maintenant, il manque en effet la description de la méthodo (pour pouvoir la critiquer) ...
Ceci dit, je suis passé par plusieurs entreprises ces dernières années, et dans toutes, une certaine proportion des développeurs (10% me paraît une bonne estimation) ne produisait pas grand chose (en tenant compte des rituels, des ateliers de conception, du run, etc.) ...
Pour certains, un changement d'orientation professionnelle aurait été une bonne idée.
Par ailleurs, j'ai croisé aussi beaucoup de développeurs qui "produisaient" beaucoup, mais la qualité de la production n'était pas exemplaire.
Mais tous les autres, je les aimais bien
Modifié le 27/11/2024 à 17h34
Un jour mon chef vient me voir et me dit : quand auras-tu corrigé le bug ?
Je lui réponds : chef, écoute, je ne sais pas encore d'où ça vient et je cherche. Quand j'aurai trouvé d'où ça vient, peut-être je pourrais te donner une estimation du temps de correction. Maintenant si tu veux m'aider à chercher, ça ira plus vite !
Du coup il est parti...
Mais il était aussi réaliste, il avait fait du code avant d'être chef.
Chef : Je sais que mon code n'était pas terrible.
Moi : Oui effectivement, mais enfin il a au moins le mérite d'exister et de fonctionner... la plupart du temps. :-)
Aujourd'hui à 18h46
Je crois que même chez les fourmies c'est prouvé qu'il y a une part d'inutiles alors bon, imaginez chez les cigales !
Aujourd'hui à 16h06
Le travail d'ingénieur ne se résume pas qu'à réaliser des commits. J'ai des périodes où je fais très peu de commits, car je passe plus de temps en analyse, sur un poc ou en calls. La "productivité" ce n'est pas pisser du code pour avoir de beaux chiffres à afficher.
Ça tombe bien, car je suis en train de lire le dernier livre de Cal Newport, Slow Productivity, et c'est exactement le type d'analyse qu'il critique dès le début (j'invite d'ailleurs à lire ses différents livres, très enrichissants, voire limite philosophiques, à ceux qui ne le connaissent pas).
Modifié le 27/11/2024 à 16h21
La méthode qui consiste à évaluer la productivité d'un "ingénieur" sur la base uniquement du nombre de lignes de code publiées a déjà été remise en cause à plusieurs reprises comme dans l'exemple donné par SebSauvage en 1982 dans l'équipe qui travaillait sur le Lisa.
Pire, une des conséquences d'un tel management ne peut que produire à terme du mauvais code.
CQFD.
EDIT: la question du timing d'un tel article me rend perplexe.
En effet, c'est précisément à l'heure où la Silicon Valley fait face à une conjecture économique difficile (sans précédent ?) qu'il est publié.
À l'heure où le dégraissage est en cours, cet article arrive à point nommé, n'est-il pas ?!
C'est comme si l'on recherchait des justifications pour les futurs licenciements ...
Aujourd'hui à 20h08
Et que le mec essaye de vendre sa soupe au passage.
Bref pas convaincu.
Aujourd'hui à 16h23
Si l'objectif n'était effectivement pas de mesurer la productivité via le nombre de lignes de code ou de commit, il n'aurait pas été nécessaire de le préciser...
Aujourd'hui à 16h24
Et je suis pas ingé soft.
Aujourd'hui à 16h28
En tout cas, ce mec ne redore pas le blason des développeurs PHP.
Aujourd'hui à 16h35
Aujourd'hui à 17h10
Aujourd'hui à 18h29
Moi ce qui m'intéresserait, c'est de savoir à quel prix il veut vendre ses analyses nocives.
Modifié le 27/11/2024 à 18h42
Le retour de la pointeuse !
Je vous offre un petit exemple, qui va vous apparaitre classique, concernant du support par tickets :
Si on considère qu'un meilleur technicien qu'un autre traite plus de tickets qu'un autre, eh bien vous aurez des baudruches (ie pleines d'air) qui vont créer/clore du ticket en masse :
* Pas répondu ? Clos
* Répondre et clore même si le problème n'est pas réglé : si le client répond cela ouvrira un autre ticket
Aujourd'hui, les services de supports, quand ils existent encore, sont soit sans humains, soit embauche des humains les moins payés possibles, donc les moins compétents possibles, à qui il faut répéter en boucle les mêmes questions pendant des semaines sans qu'aucune réponse ne soit apportée.
À leurs messages d'une ligne, il faut répondre en détails et tester de son côté : il ne font rien, produisent rien, ne testent rien eux-même.
Ce monde du support est l'évolution naturelle d'une approche quantitative.
En définitive, l'approche quantitative (la seule mesurable, parce que la qualitative… bon courage pour ne pas obtenir une usine à gaz arbitraire & injuste) amène simplement à un renforcement des baudruches.
Définir un "bon" ingénieur par un volume de commits, c'est la même chose.
Sombre idée, et vous allez vénérer des robots-baudruches en aliénant d'autres, dont le travail ne se translate pas directement en commit.
Décidément, la tentation fasciste n'est jamais loin dans les modèles autoritaires/arbitraires qui forment le monde l'entreprise d'une certaine idéologie.
Aujourd'hui à 18h43
Parce que même si on oubli la méthodo pourrie, les ingés n'ont pas de "productivité" fixe. Il suffit qu'un môme soit malade, puis refile la maladie à l'autre môme, pour que tu passes un mois sans dormir correctement, et avec une productivité quasi nulle, ce qui ne veut pas dire que t'es un mauvais ingé.
Mettre des métriques sur l'humain ne fonctionne simplement pas.
Modifié le 27/11/2024 à 19h06
Pour l'exercice rapide, si j'en crois wikipedia: "Un ingénieur logiciel est une personne qui applique les principes du génie logiciel pour analyser, concevoir, développer, tester, évaluer et maintenir des logiciels." ici le monsieur n'évalue que la partie développer (sic) et même ça il le fait très mal (sic bis).
- Est-ce qu'un senior doit produire beaucoup de commit ou faire d'avantage du peer review pour améliorer le code des junior? est-ce que le rôle d'un lead est de produire du code en masse? (bref, un métier, plusieurs séniorité et rôle ...)
- Sinon, comment évaluer les utilisations pas optimum de git (rebase en local pour commit en une fois une feature plutôt que de passer par une branches, coder en local et push une fois à autre pcq on comprends pas git, les bypass pour fixer rapidement en prod le vendredi soir ce qui ressort pas dans l'historique ...)
- BTW, ça doit faire 25 ans que la LoC est considérée comme mauvaise KPI pour évaluer une productivité ... (pas plus tard que début du mois, une news est passé sur intel qui améliore de 3500% les performances en modifiant une seule ligne de code ...)
- Bref, c'est sans fin (et on parle même pas du contexte externe, des réunionites aigu et autre facteur externe pourrissant le job).
En vrai, avec une pointe défaitisme et de sarcasme, ça donne juste envie de créer une startup future licorne IA based mon cul sur la commode qui améliore la productivité des ingénieurs logiciels et de lever des millions d'euro avec pour toute technologie un git hook qui split les commits en plusieurs commit ou qui en ajoute d'autre avec du vent (fichier vide, commentaire inutile, voir qui crée des fix en retirant des fichiers vide crée par des commits précédant ...).
Sick sad world !
PS: du reste, ça retire rien au fait qu'il y a sans doute bien 10% d'ingé logiciel qui en glande pas une (pour de bonne ou de mauvaise raison, mais ça change rien au fond du sujet ...)
Aujourd'hui à 20h08
La question la plus importante, au-delà de la méthodologie, c'est : Qui a commandé l'étude ?
De nos jours (et surtout malheureusement) la science est très prompte à souffler dans le sens du chéquier.
Aujourd'hui à 21h28
mais bon, c'est pas comme si sa "méthode" avait été débunkée y'a plus de 30 ans, hein...
https://folklore.org/Negative_2000_Lines_Of_Code.html
Aujourd'hui à 21h39
Aujourd'hui à 21h47
Aujourd'hui à 21h57