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 personne 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 (65)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 27/11/2024 à 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.
Le 27/11/2024 à 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 :)
Le 27/11/2024 à 15h37
Le 28/11/2024 à 14h35
enjoy
j'appelle ça un torchon.
Le 27/11/2024 à 15h46
Le 27/11/2024 à 15h57
Le 27/11/2024 à 16h51
Le 27/11/2024 à 17h54
Le 27/11/2024 à 15h53
Le 27/11/2024 à 15h54
Le 28/11/2024 à 09h17
Ou des équipes sécurités qui fournissent des recommandations et pas juste des "coups de tampons" (et encore, quand il y en a un...),
et soyons fous, des responsables contrats qui ont des templates standardisés avec les clauses juridiques applicables de l'entreprise !
Le 28/11/2024 à 09h35
Des génies !
Le 28/11/2024 à 09h59
Le 28/11/2024 à 12h49
Trouver des RH qui fassent vraiment de la gestion de l'humain et pas juste de l'administratif, c'est exceptionnel.
Ou des internes dans des grosses boites qui ne soient pas juste des boites aux lettres entre les services qui font passe-plat pour les externes.
Le 27/11/2024 à 16h00
Modifié le 27/11/2024 à 17h25
Le 27/11/2024 à 22h53
Le 28/11/2024 à 09h46
svn blame
existait déjà et la commandecommit
indique qu’il faut commettre (le méfait ?) donc ça reste dans la logique (oui, le verbecommit
a plusieurs sens mais quand même).Le 28/11/2024 à 08h39
Le 27/11/2024 à 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
Le 27/11/2024 à 16h11
--date
🙄Le 27/11/2024 à 19h24
Le 28/11/2024 à 10h59
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. :-)
Le 27/11/2024 à 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 !
Le 29/11/2024 à 08h41
On a aussi prouvé la mauvaise foi et la fainéantise chez les abeilles si pas assez de récompense.
Le 29/11/2024 à 08h43
Et de même, plus tu fous la grouille avec tes bugs, plus tu peux commiter tes corrections. Ca c'est bosser.
Le 27/11/2024 à 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 ...
Le 27/11/2024 à 20h08
Et que le mec essaye de vendre sa soupe au passage.
Bref pas convaincu.
Le 27/11/2024 à 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...
Le 27/11/2024 à 16h24
Et je suis pas ingé soft.
Le 27/11/2024 à 16h28
En tout cas, ce mec ne redore pas le blason des développeurs PHP.
Le 27/11/2024 à 16h35
Le 28/11/2024 à 10h12
Le 29/11/2024 à 15h33
Modifié le 29/11/2024 à 16h34
qualité et prix bas ! pour le BF, 3 lignes achetées 2 lignes payées
Le 07/12/2024 à 04h14
i +
1;
?
Le 27/11/2024 à 17h10
Le 27/11/2024 à 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.
Le 27/11/2024 à 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 ...)
Le 07/12/2024 à 04h18
Le 07/12/2024 à 13h02
Aujourd'hui à 14h08
Bon, qui ça te gêne si j'utilise ton idée ? Qui veut s'associer pour monter un business.
WindCode. Develop faster, for the cloud. (*)
* Faster. Not better. Not even useful. Just more code.
Le 27/11/2024 à 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.
Modifié le 10/12/2024 à 14h06
Le 27/11/2024 à 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
Le 27/11/2024 à 21h39
Le 27/11/2024 à 21h47
Le 27/11/2024 à 21h57
Le 28/11/2024 à 07h13
Et quand je m'aperçois que j'en écris aussi, ça ne doit pas être réservé au secteur 😜
Sans même parler de tous les parasites d'actionnaires qui s'enrichissent sur le labeur des travailleurs, Une vision très étriqué du monde du travail cette "étude", mais au moins ça fait gratter un paquet de monde 😁
Le 28/11/2024 à 09h23
Le 28/11/2024 à 09h24
Le 28/11/2024 à 11h23
Plus de la moitié des personnes ayant accès au repo ne font pas de code (manager, qualité, testeur). La méthodologie me parait un peu foireuse.
Le 28/11/2024 à 12h44
Tout le monde acquiesce quand on parle de bullshit job mais si on pointe les ingés, ça se peut pas car on est on magiquement épargnés
Le 28/11/2024 à 16h32
Modifié le 02/12/2024 à 11h50
Le relativisme ne permet pas de piloter une entreprise, si tu veux compenser justement ceux qui s'impliquent il faut savoir discriminer sur l'impact (ce qui est un sujet difficile)
Le 30/11/2024 à 20h22
Le 28/11/2024 à 13h42
Le 29/11/2024 à 12h34
Le 01/12/2024 à 11h01
Premièrement un ingénieur logiciel n'est pas un pisseur de code !
C'est avant tout du du conseil : comprendre le besoin, chercher les différentes façon d'y répondre, et identifier la bonne selon différents critères (la réponse au besoin, le coût, la maintenabilité, la sécurité, les perf...).
Le bon conseil est parfois... de ne pas faire de code. Les plus mauvais dev' sont ceux qui écoutent à moitié le besoin et courent coder et tordre leur logiciel / framework qu'ils connaissent, coûte que côute pour répondre au besoin.
L'ingénieur logiciel a également d'autres casquettes : il pond des specs, des tests, des docs de formations utilisateurs, anime des ateliers UX, organise la formation technique de ses collègues...
En admettant, qu'on ne souhaiterait que mesurer la capacité à pisser du code, le nombre de commit n'est pas un bon indicateur :
Comment est considéré un commit un peu gros contenant une grosse feature, et n'ayant généré aucune régression ? à l'inverse un dev qui commit à tout-va ne teste jamais rien et génère 4 - 5 régressions à chaque fois qu'il touche du code, serait bien vu car il aurait beaucoup de commit à son actif ?