Connexion
Abonnez-vous

Selon une étude, près de 10 % des ingénieurs logiciels « ne font pratiquement rien »

Le 27 novembre à 15h30

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.

Abonnez-vous
votre avatar
Hmmm... Je lisais des réactions sur cette étude hier et ...
- quid de la méthodologie ?
- quid de la prise en compte de l'encadrement (un bouffe temps comme pas permis) ?
votre avatar
Et des RCA sur les pb client, qui peuvent être très consommateurs, des phases spécification etc... Ne se baser que sur les commit c'est limité. Puis on peut faire un commit unique d'un gros boulot cassant si on le split... ou des dizaines pour des petites merdes qu'une IA aurait pu coder.
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.
votre avatar
Il n'est pas vraiment question d'un système de gestion de conf précis, juste de commits.

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 certes des pb de réplication à leurs admins mais en comparaison très peu et autant aux développeurs. Git a inversé 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 :)
votre avatar
Ils ont juste l'air de dire que pas de ligne de code sur les dépôts de l'entreprise = ingé qui fait rien
votre avatar
C'est moi où toute les parties conception, échanges sur les tickets, partage de connaissances, aide de collègues sont oubliées ?
votre avatar
et débogage, car des fois changer un caractère peux prendre plusieurs heures d'investigations.
votre avatar
Ça, ça pourra se voir dans le commit.
votre avatar
Et toute la dimension humaine (conduite de projet, du changement, psychosociologie de l'entreprise) ainsi que la veille technologique (d'ailleurs, c'est pas un peu ce qu'on fait ici sur nos heures de boulot ? :3)
votre avatar
près de 10 % des ingénieurs logiciels « ne font pratiquement rien »
que dire de 90% des CEO...
votre avatar
Easy tiger.
votre avatar
Quel balance ce Git....
votre avatar
J'ai toujours trouvé suspecte cette commande "blame" de git, qui balance celui ou celle qui devra porter le bonnet d'âne.
votre avatar
J'avoue que le nom de la commande me semble mal choisie, car très violente... Mais bon, sur une techno appelée "connard"...
votre avatar
Le nombre de commit est une mauvaise mesure !
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
votre avatar
C'est comme les boites qui regarde l'heure des commits pour savoir si tu travailles bien. Ils ne doivent pas connaitre l'option --date 🙄
votre avatar
Je ne connaissais pas perso !
votre avatar
La méthodologie ne s'appuie pas uniquement sur le nombre de commits : le graphe [[https://next.ink/wp-content/uploads/2024/11/StanfordCommits.png]] indique la répartition du nombre de commits/mois pour les "ingénieurs fantômes".
Maintenant, il manque en effet la description de la méthodo (pour pouvoir la critiquer) ... :D

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 :D :love:
votre avatar
Oui tout à fait, une estimation "à la louche" de 10% est tout aussi valide !

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. :-)
votre avatar
Et moi je suis dans l'industrie et on trouvera sans probleme 10% d'inefficace en mécanique/ usine aussi !

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 !
votre avatar
C'est quoi cette méthodologie de merde ? (je mesure l'usage de la vulgarité ici)

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).
votre avatar
Je vais paraphraser ce que SebSauvage a écrit : https://sebsauvage.net/links/?PGtm_A

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 ...
votre avatar
Sans parler du fait que le gars explique que c'est dans ceux qui bossent en télétravail que le pourcentage est le plus élevé (quand tous les gros veulent faire revenir les gens au bureau).

Et que le mec essaye de vendre sa soupe au passage.

Bref pas convaincu.
votre avatar
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 ».

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...

:fumer:
votre avatar
Surrout que ce sont des repos privés de ce que je comprends. Je peux pas partager ceux de ma boîte pourtant c'est ceux là qui sont alimentés. Le mien perso ne bouge plus depuis quelques temps maintenant.
Et je suis pas ingé soft.
votre avatar
Un ingénieur logiciel n'est pas un coder.
En tout cas, ce mec ne redore pas le blason des développeurs PHP.
votre avatar
mouais bof, moi j'suis payé au nombre de lignes dans mon code :fume:
votre avatar
Mais ce n'est pas forcément de leur faute. Si on ne leur demande rien logique qu'ils ne fassent rien.
votre avatar
Viiite, remplaçons tous les devs par des IA qui pondront 10x plus de code tous les jours. Merci Yegor pour toutes ces belles économies à venir.
Moi ce qui m'intéresserait, c'est de savoir à quel prix il veut vendre ses analyses nocives.
votre avatar
Ah, l'éternelle tentation du flicage !
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.
votre avatar
Et ce genre "d'étude" va être la source utilisée pour virer ~10% des employés. Sauf que le pourcentage d'ingés ne foutant rien sera toujours le même après.

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.
votre avatar
Il y a tellement de truc qui vont pas dans cette analyse que j'avoue avoir un peu de mal à comprendre qu'elle soit relayé (no offense).

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 ...)
votre avatar
Effectivement la conception ne fait pas bouger le clavier hein. Et c'est bien souvent (quand c'est bien fait) un truc qui ne fait pas de commit et qui consomme plus de temps que le développement.

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.
votre avatar
dev ≠ pisse-code
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
votre avatar
L'évaluation par le nombre de commits a t'il un lien dans la démarche avec le hindex ?
votre avatar
C'est génial, on se rend compte (certains depuis un moment, d'autres qui commencent à se réveiller) que le volume de production scientifique est un indicateur à la zouave, et des gloglos se mettent à imaginer pareil sur le nombre de lignes de code (ce qui est encore pire, car on peut commiter beaucoup en passant son temps à réparer des erreurs dues à la production hâtive de code). J'ai l'impression que la notion de RETEX (déjà appliquée souvent d'une façon assez risible dans les administrations et les entreprises) est clairement absente (on peut analyser ce que font les autres et en bénéficier).
votre avatar
Commit or not commit. That is the question :fumer:

Selon une étude, près de 10 % des ingénieurs logiciels « ne font pratiquement rien »

Fermer