“Un bon programmeur peut être 10 fois plus productif qu'un médiocre” [fermé]

J'avais lu une interview d’un grand programmeur (ce n’est pas en anglais) dans laquelle il disait qu ’" un bon programmeur peut être 10 fois plus performant qu'un médiocre ", ce qui explique pourquoi les bons programmeurs sont très bien payés et pourquoi les sociétés de programmation offrent de nombreuses installations à leurs employés. L'idée était qu'il y avait une très forte demande pour de bons programmeurs, à cause de la raison ci-dessus et c'est pourquoi les entreprises paient beaucoup pour les amener.

Êtes-vous d'accord avec ce constat? Connaissez-vous des faits objectifs qui pourraient l’appuyer?

Edit: La question n'a rien à voir avec l'expérience. si vous parlez d'un grand programmeur avec 1 an d'expérience, il devrait être 10 fois plus productif qu'un programmeur médiocre avec 1 an d'expérience. Je conviens que, à partir de certaines années d’expérience, les choses commencent à se dissiper, mais ce n’est pas l’objet de la question.

Steve McConnell a rédigé deux articles sur les différences de productivité .

• Variations de productivité entre les développeurs de logiciels et les équipes: l'origine de "10x"

• Origins of 10X - Quelle est la validité de la recherche sous-jacente?

Le premier article ( Variations de productivité ... ) dit:

... Sackman, Erikson et Grant (1968) ont mené à la fin des années 1960 une étude sur les énormes variations dans la productivité des programmes individuels. Ils ont étudié des programmeurs professionnels avec une expérience moyenne de 7 ans et ont constaté que le rapport du temps de codage initial entre le meilleur et le pire programmeur était d'environ 20 à 1; le rapport des temps de débogage sur 25 à 1; de la taille du programme 5 à 1; et de la vitesse d'exécution du programme d'environ 10 à 1. Ils n'ont trouvé aucune relation entre la quantité d'expérience d'un programmeur et la qualité du code ou la productivité.

Un examen détaillé des conclusions de Sackman, Erickson et Grant révèle quelques failles dans leur méthodologie ... Cependant, même après avoir pris en compte ces failles, leurs données montrent toujours une différence de plus de 10 fois entre les meilleurs et les pires programmeurs.

Au cours des années écoulées depuis l'étude initiale, de nombreuses autres études de programmeurs professionnels ont confirmé la conclusion générale selon laquelle "il existe des différences d'ordre de grandeur entre programmeurs" (Curtis 1981, Mills 1983, DeMarco et Lister 1985, Curtis et al. 1986). , Carte 1987, Boehm et Papaccio 1988, Valett et McGarry 1989, Boehm et al 2000) ...

^{Cet article a aussi une note intéressante:}

^{Ce degré de variation n'est pas propre au logiciel. Une étude de Norm Augustine a révélé que, dans diverses professions - écriture, football, invention, travail policier et autres professions - les 20% les plus performants produisaient environ 50% de la production, qu’il s’agisse de touchés, de brevets , cas résolus ou logiciels (Augustine 1979).}

Le deuxième article ( ... Quelle est la validité de la recherche sous-jacente? ) A été écrit principalement pour aborder la critique du premier article de Laurent Bossavit :

• Critique originale en français: Folklore ou fait scientifique, comment les différencier
• Traduction anglaise: Fact et folklore en génie logiciel .

Dans le deuxième article, dans la section A approfondir ses recherches sur le thème "10x", McConnell revérifie plus en détail les références utilisées dans le premier article et conclut:

... Après avoir revu ces citations une nouvelle fois en écrivant cet article, j'ai conclu à nouveau qu'elles étayaient la conclusion générale selon laquelle il existe des différences de productivité 10 fois supérieures entre les programmeurs. Les études ont collectivement impliqué des centaines de programmeurs professionnels dans un large éventail d'activités de programmation.

... le corpus de recherches à l'appui de l'allégation 10x est aussi solide que toute recherche effectuée en génie logiciel. Les études à l’appui de la revendication 10x ne sont pas soumises à la limitation méthodologique décrite à la figure 1, car elles étudient la variabilité individuelle elle-même (c’est-à-dire uniquement le côté gauche de la figure). Bossavit ne cite pas même une étude - imparfaite ou autre - qui contredit l'allégation 10x, et je n'ai pas vu d'études de ce type non plus. Le fait qu'aucune étude n'ait abouti à des résultats contredisant l'allégation 10x donne encore plus de confiance dans l'allégation 10x. Quand je considère le nombre d’études qui ont été effectuées, je trouve globalement que la recherche est non seulement suggestive, mais concluante - ce qui est rare dans la recherche en génie logiciel.

Par souci d’exhaustivité, la liste des références utilisées dans les variations de productivité ... est également citée ci-dessous:

Références

Augustine, NR 1979. "Lois d'Augustin et principaux programmes de développement de systèmes." Examen de la gestion des systèmes de défense: 50-76.

Boehm, Barry W. et Philip N. Papaccio. 1988. "Comprendre et contrôler les coûts des logiciels." Transactions IEEE sur le génie logiciel SE-14, no. 10 (octobre): 1462-77.

Boehm, Barry et al, 2000. Estimation des coûts logiciels avec Cocomo II, Boston, Massachusetts: Addison Wesley, 2000.

Boehm, Barry W., TE Grey et T. Seewaldt. 1984. "Le prototypage par rapport à la spécification: une expérience multiprojet." Transactions IEEE sur le génie logiciel SE-10, no. 3 (mai): 290-303. Toujours dans Jones 1986b.

Card, David N. 1987. "Un programme d'évaluation de la technologie logicielle." Technologie de l'information et des logiciels 29, no. 6 (juillet / août): 291-300.

Curtis, Bill. 1981. "Variabilité du programmeur de corroboration." Actes de la conférence IEEE 69, no. 7: 846.

Curtis, Bill et al. 1986. "Psychologie logicielle: le besoin d'un programme interdisciplinaire." Actes de la conférence IEEE 74, no. 8: 1092-1106.

DeMarco, Tom et Timothy Lister. 1985. "Performance du programmeur et les effets du lieu de travail." Actes de la 8ème Conférence internationale sur le génie logiciel. Washington, DC: Presse de la société IEEE Computer Society, 268-72.

DeMarco, Tom et Timothy Lister, 1999. Peopleware: Projets et équipes productifs, 2e éd. New York: Maison Dorset, 1999.

Mills, Harlan D. 1983. Productivité des logiciels. Boston, Mass.: Little, Brown.

Sackman, H., WJ Erikson et EE Grant. 1968. "Études expérimentales exploratoires comparant les performances de programmation en ligne et hors ligne." Communications de l'ACM 11, no. 1 (janvier): 3-11.

Valett, J. et FE McGarry. 1989. "Résumé des expériences de mesure logicielle dans le laboratoire de génie logiciel." Journal of Systems and Software 9, no. 2 (février): 137-48.

Weinberg, Gerald M. et Edward L. Schulman. 1974. "Objectifs et performance en programmation informatique." Facteurs humains 16, no. 1 (février): 70-77.

Un programmeur véritablement redoutable peut avoir une productivité inférieure à zéro (les bugs qu’ils introduisent prennent plus de temps à corriger qu’il ne le faudrait pour faire tout leur travail à leur place).

Et un véritable programmeur peut faire des choses que les programmeurs pauvres et moyens ne réaliseraient tout simplement jamais , peu importe le temps que vous leur avez imparti.

Donc, pour ces raisons, il est difficile de parler de "10x comme productif" ou de "100x comme productif".

La chose à retenir, cependant, est que la plupart des employeurs de programmeurs n’ont pas besoin de faire les tâches difficiles que les programmeurs moyens ne pourraient pas gérer. La plupart du code en cours d’écriture sont des sites Web, des applications métiers, des applications intranet, etc. Le programmeur productif de cet environnement est celui qui est le mieux à même de comprendre et de mettre en œuvre les besoins des utilisateurs, et non celui qui peut écrire le code le plus intelligent.

En effet, la plupart des employeurs de programmeurs auraient intérêt à avoir un bon programmeur plutôt qu’un excellent, car le bon s’ennuiera et partira. Je dois trouver un bon match entre les programmeurs et les emplois.

Faits et sophismes du génie logiciel (Fait 2, disponible dans l'aperçu amazon):

Les meilleurs programmeurs sont jusqu'à 28 fois meilleurs que les pires, selon la recherche sur les "différences individuelles". Étant donné que leur salaire n’est jamais proportionné, ils représentent la plus grande aubaine dans le domaine des logiciels.

(regardez la liste des sources pour la recherche)

Bien sûr, si vous comparez la productivité d'un non-programmeur (ou d'un très mauvais programmeur) avec le bon (en termes d'expérience et de connaissances), la différence peut être infiniment grande ( n/0 == infinitypour tout positif n), mais ce n'est pas juste ni comparaison raisonnable.

Votre salaire peut dépendre de plusieurs facteurs (dans un ordre aléatoire):

• Technologies utilisées
• Pays / Etat dans lequel vous travaillez
• Richesse de l'entreprise
• Type d'entreprise de l'entreprise
• Nombre de développeurs dans l'entreprise
• Combien de temps travaillez-vous dans l'entreprise
• Politiques de bureau

avec votre personnel ...

• productivité
• connaissance et expérience
• implication dans les affaires de l'entreprise (pour les startups)
• les compétences de négociation
• attractivité et compétences sexuelles, lol (enfin, l'intelligence est sexy)

Ma réponse est "oui, mais faites attention à la façon dont vous utilisez cette métrique".

Un programmeur qui fonctionne, dirons-nous, de manière optimale, est celui qui crée pour la fonctionnalité et provoque moins d’erreurs qui doivent être corrigées que son bretheren moins performant. Je n'aurais pas du mal à croire que ces personnes puissent multiplier par 10 le rendement des autres, en particulier si l'on considère qu'un seul bon ou mauvais choix fait en une heure peut facilement avoir un impact de 10 heures, et les programmeurs font de tels choix. la plupart des jours.

Mais...

Vous devez être prudent dans vous mesurez cela. Je ne fais vraiment pas confiance à la plupart des mesures de productivité depuis que j'ai vu d'innombrables cas où à peu près toutes les mesures connues ne prenaient pas en compte un élément que je considère essentiel pour la productivité de l'équipe. Donc, je déteste généralement de tels chiffres pour la "productivité". Voici quelques exemples:

• Lignes de code (LOC) - une métrique généralement détestée, puisqu'un programmeur irréfléchi peut générer beaucoup de lignes de code horribles, verbeuses, inefficaces et difficiles à déboguer, tandis qu'un bon programmeur crée quelques lignes de code élégantes, faciles à corriger et rarement brisées. dans plus de temps, mais qui sont globalement un meilleur choix.
• Bugs générés et / ou le temps de corriger - tout le monde va générer des bugs, et souvent les bugs les plus coûteux sont générés par une série de mauvaises décisions pour lesquelles le générateur du problème est simplement le dernier de l’effet domino. En outre, vos grands débogueurs ne sont pas toujours vos grands concepteurs - vous avez besoin des deux.
• Selon presque tous les indicateurs, il existe d’excellents développeurs qui sont si pénibles à avoir pour une équipe, qu’un développeur «super productif» chassera 10 bons développeurs et que je vois rarement quelqu'un qui peut tout faire correctement, nous aurons donc besoin de plus d'une personne sur le projet.
• Il n’existe aucun moyen de rendre facilement compte de ces personnes formidables qui voient les problèmes se poser avant d’être sérieuses et les résolvent, en particulier lorsque le problème est une faille dans un processus - CM défectueux, construction inefficace, une lacune dans les tests, une faille de sécurité - ces Cela vous fait souvent penser à une grosse perte de temps jusqu'à ce que vous réalisiez qu'ils vous épargnent des catastrophes - il n'y a aucun moyen de mesurer cela.
• En outre, il existe des personnes que je considère nécessaires dans une équipe d'une certaine taille que je qualifierais de "bâtisseurs de cohésion" - rarement le sommet absolu de la productivité, elles restent généralement dans les 20% supérieurs et elles font le travail inestimable d'aider à monter en puissance les nouvelles personnes, en reliant les points et en s'assurant que les bonnes questions sont posées et que les bonnes personnes restent au courant, ils écrivent (sans demander!) la pièce clé de la documentation à laquelle tout le monde se réfère, car il ne s'agit pas seulement du bon document, mais c'est mis dans le bon sens. Si vous voulez que 10 personnes travaillent au maximum de leur efficacité, vous avez absolument besoin de l'une de ces personnes et vous ne l'obtiendrez pas si vous mettez 10 super développeurs dans une pièce.

De nombreux systèmes de mesure ont essayé de prendre en compte ces facteurs, mais je ne me suis pas encore rendu compte qu'il en existe un qui tient compte de tous ces problèmes. médiocre "parce que je me demande si la métrique représente vraiment tout le travail nécessaire pour réussir un produit en cours ou une équipe prospère et prospère.

Donc, ma grande mise en garde est: qu'allez-vous faire avec cette métrique? J'utiliserai quelque chose comme ceci pour savoir que les bons outils et le bon talent peuvent causer une grande différence dans la façon dont le travail est effectué, mais si vous essayez d'optimiser une équipe où chaque individu produit 10 fois le résultat "typique", vous êtes voué à un cas de frustration. Mieux vaut trouver un moyen d’amener votre équipe à faire deux à trois fois plus que ce qu’elle faisait auparavant en travaillant mieux ensemble.

Dans son livre intitulé Les lutins du génie logiciel , Laurent Bossavit décrit la recherche de l'allégation de productivité 10x. Il a découvert qu’il n’existait pas de chiffres sonores derrière cette affirmation. L’affirmation est passée de la spéculation à la "réalité" par un jeu téléphonique de réclamations successivement plus concrètes en citation. L'article de blog qui comprend le chapitre sur la revendication 10x, ainsi que les citations et citations inexactes pertinentes, est factuel et folklorique en génie logiciel .

Voici ce qu’il a trouvé: Quelqu'un en 1968 a fait une étude comparant les personnes résolvant un problème de débogage particulier, et a découvert que certaines d’entre elles le faisaient 10 fois plus vite que d’autres. Nous pourrions en conclure que certaines personnes sont dix fois plus efficaces pour résoudre ce problème , ou que certaines personnes ont eu de la chance , ou une grande variété de choses différentes. Certaines personnes ont choisi de citer ceci (toutes ces paraphrases) "une étude (Sackman et al, 1968) a révélé que certains programmeurs travaillent dix fois plus vite que d’autres". Il est ensuite devenu "des études ont montré que les bons programmeurs sont 10 fois meilleurs que la moyenne", puis enfin "il est notoire que la productivité des programmeurs varie de 10 fois entre individus". Ensuite, quelqu'un collecte toutes ces citations, citant à tort une source originale dire "beaucoup de chercheurs croient…".

Bien sûr, ce ne serait pas un jeu de téléphone si seulement la véracité de l'affirmation changeait: le multiplicateur va également à 11 et au-delà .

" Le programmeur productif de cet environnement est celui qui sait le mieux comprendre et implémenter les besoins des utilisateurs, et non celui qui écrit le code le plus intelligent. " ( Réponse de Carson63000 )

Ce point clé couplé avec bethlakshmiLes points de fait un point énorme. Un bon développeur peut être formidable dans sa tranche de réalité mais se briser dès que le monde change. Être capable de répondre aux besoins de l'entreprise est beaucoup plus important que toute autre chose. En fin de compte, à moins que votre entreprise soit une technologie, elle ne se soucie pas de la technologie; ils ont besoin de solutions. Donc, être excellent avec les modèles de conception ne signifie pas forcément être squatté pour les utilisateurs finaux qui ont juste besoin d'un vidage de données à afficher sur une page Web. J'ai vu des développeurs médiocres obtenir un emploi en s'adressant à l'entreprise qui les soutient, tandis que de grands développeurs s'ennuient et se retirent à la recherche d'un défi sans fin. En fonction de votre organisation et de vos projets, il est possible de nourrir ces développeurs en manque de ressources, mais il est probable qu’il y aura un moment où vous ne ferez rien. t besoin de cette quantité de puissance de traitement. Ces développeurs n'aiment pas rester inactifs, comme un processeur. Ils vont arrêter et redémarrer ailleurs.

Enfin, je dirai qu’il n’est pas difficile de savoir qui sont vos interprètes "clés", mais une "équipe" de développement est toujours une équipe. Pour répéter bethlakshmi, "qu'allez -vous faire avec cette métrique?""Si vous avez besoin d'une équipe qui se comporte comme une équipe, je ne me concentrerais pas sur des métriques. Je réaliserais que même le plus petit joueur reste un élément important de l'équipe. Même avec 60% de moins que la productivité de votre clé joueur, ce joueur peut donner à votre équipe quelque chose dont il a besoin. Découvrez ce que c'est et essayez de le multiplier. N'épuisez pas votre joueur clé en supposant qu'il devrait diriger l'équipe, trouvez également des moyens de multiplier sa production, en contaminant les autres joueurs avec cette grandeur. Cela nécessite un peu de créativité, pas seulement des chiffres. En fin de compte, vous pouvez apprendre que ce qui fait un bon programmeur n'est même pas ce programmeur, ce peuvent être ses pairs, ses opportunités sur le lieu de travail ou ce pourrait même être vous.