web-dev-qa-db-fra.com

"Un bon programmeur peut être 10 fois plus productif qu'un médiocre"

J'avais lu une interview avec un grand programmeur (ce n'est pas en anglais) et dans celui-ci il a dit qu '"un grand programmeur peut être 10 fois plus bon qu'un médiocre", expliquant 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 a une très grande demande pour de bons programmeurs, pour la raison ci-dessus et c'est pourquoi les entreprises paient beaucoup pour les apporter.

Êtes-vous d'accord avec ce constat? Connaissez-vous des faits objectifs qui pourraient le soutenir?

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

productivitymanagement
54
m3th0dman

Un aperçu assez complet et une analyse des recherches sur les différences de productivité sont fournis dans deux articles écrits par Steve McConnell :

Le premier article ( Variations de productivité ...) déclare:

... L'étude originale qui a trouvé d'énormes variations dans la productivité des programmes individuels a été menée à la fin des années 1960 par Sackman, Erikson et Grant (1968). Ils ont étudié des programmeurs professionnels avec une moyenne de 7 ans d’expérience et ont constaté que le rapport du temps de codage initial entre les meilleurs et les pires programmeurs était d’environ 20 pour 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é ou la productivité du code.

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

Dans les années qui ont suivi l'étude initiale, la conclusion générale selon laquelle "il existe des différences d'ordre de grandeur entre les programmeurs" a été confirmée par de nombreuses autres études sur les programmeurs professionnels (Curtis 1981, Mills 1983, DeMarco et Lister 1985, Curtis et al. 1986 , Card 1987, Boehm et Papaccio 1988, Valett et McGarry 1989, Boehm et al 2000) ...

Cet article a également une note latérale intéressante:

Ce degré de variation n'est pas propre aux logiciels. Une étude de Norm Augustine a révélé que dans une variété de professions - écriture, football, invention, police travail et autres occupations - les 20 pour cent les plus riches de la population ont produit environ 50 pour cent de la production, que ce soit des atterrissages, des brevets, des cas résolus ou des logiciels (Augustine 1979).

Deuxième article (... Quelle est la validité de la recherche sous-jacente?) a été écrit principalement pour répondre à l'examen critique du premier par Laurent Bossavit :

Dans le deuxième article, dans la section Une plongée plus profonde dans la recherche soutenant "10x" McConnell revérifie plus en détail les références utilisées dans le premier article et conclut:

... En examinant à nouveau ces citations en écrivant cet article, j'ai conclu à nouveau qu'elles soutiennent la constatation générale qu'il existe des différences de productivité 10x entre les programmeurs. Les études ont collectivement impliqué des centaines de programmeurs professionnels dans un éventail d'activités de programmation.

... le corpus de recherches qui soutient la revendication 10x est aussi solide que toute recherche effectuée en génie logiciel. Les études qui soutiennent la revendication 10x ne sont singulièrement pas soumises à la limitation méthodologique décrite dans 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 une seule étude - erronée ou non - qui contrecarre la revendication 10x, et je n'ai pas vu de telles études non plus. Le fait qu'aucune étude n'ait produit de résultats qui contredisent la revendication 10x donne encore plus de confiance dans la revendication 10x. Quand je considère le nombre d'études qui ont été faites, dans l'ensemble, je trouve que la recherche n'est pas 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 le Variations de productivité ... est également citée ci-dessous:

Références

Augustine, N. R. 1979. "Augustine’s Laws and Major System Development Programs". 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, Mass.: Addison Wesley, 2000.

Boehm, Barry W., T. E. Gray et T. Seewaldt. 1984. "Prototyping Versus Specifying: A Multiproject Experiment". Transactions IEEE sur le génie logiciel SE-10, no. 3 (mai): 290-303. Également dans Jones 1986b.

Card, David N. 1987. "A Software Technology Evaluation Program". Technologies de l'information et des logiciels 29, no. 6 (juillet/août): 291-300.

Curtis, Bill. 1981. "Substantifying Programmer Variability". Actes de l'IEEE 69, no. 7: 846.

Curtis, Bill et al. 1986. "Psychologie logicielle: la nécessité d'un programme interdisciplinaire". Actes de l'IEEE 74, no. 8: 1092-1106.

DeMarco, Tom et Timothy Lister. 1985. "Performance du programmeur et effets du milieu de travail". Actes de la 8e Conférence internationale sur le génie logiciel. Washington, D.C .: IEEE Computer Society Press, 268-72.

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

Mills, Harlan D. 1983. Productivité logicielle. Boston, Massachusetts: Little, Brown.

Sackman, H., W.J. Erikson et E. E. 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 F. E. McGarry. 1989. "Un résumé des expériences de mesure de logiciels dans le laboratoire de génie logiciel". Journal des systèmes et logiciels 9, no. 2 (février): 137-48.

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

41
gnat

Un programmeur vraiment terrible peut avoir une productivité inférieure à zéro (les bogues qu'ils introduisent prennent plus de temps à corriger qu'il ne faudrait pour faire tout leur travail pour eux).

Et un programmeur vraiment génial peut faire des choses que les programmeurs pauvres et moyens pourraient simplement jamais réaliser, quel que soit le temps que vous leur avez donné.

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

La chose à retenir, cependant, est que la plupart des employeurs de programmeurs n'ont pas besoin d'effectuer les tâches difficiles que les programmeurs moyens ne pouvaient pas gérer. La plupart du code écrit est des sites Web, des applications métier, des applications intranet, etc., la plupart n'étant vraiment pas si difficiles. Le programmeur productif dans cet environnement est celui qui est le mieux à même de comprendre et de mettre en œuvre les besoins des utilisateurs, pas celui qui peut écrire le code le plus intelligent.

En effet, la plupart des employeurs de programmeurs feraient mieux d'avoir un bon programmeur plutôt qu'un excellent, car le grand s'ennuiera et partira. Je dois trouver une bonne correspondance entre les programmeurs et les emplois.

92
Carson63000

Facts and Fallacies of Software Engineering states (Fact 2, available in Amazon preview):

Selon les recherches sur les "différences individuelles", les meilleurs programmeurs sont jusqu'à 28 fois meilleurs que les pires programmeurs. Étant donné que leur salaire n'est jamais proportionné, ce sont les meilleures affaires 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 la bonne (en termes d'expérience et de connaissances), la différence peut être infiniment grande (n/0 == infinity pour tout positif n), mais ce n'est ni une comparaison juste ni sensée.

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

  • Technologies utilisées
  • Pays/état 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)
30
scriptin

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

Un programmeur qui, dirons-nous, fonctionne de manière optimale, est celui qui crée pour la fonctionnalité et provoque moins d'erreurs qui doivent être corrigées que son frère moins performant. Je ne trouverais pas difficile de croire que ces gens peuvent atteindre 10 fois la productivité des autres, en particulier si l'on considère qu'un seul bon ou mauvais choix fait en une heure peut facilement avoir 10 heures d'impact, et les programmeurs font de nombreux choix de ce type. la plupart des jours.

Mais...

Vous devez être prudent lorsque vous mesurez cela. Je ne fais vraiment pas confiance à la plupart des mesures de la productivité, car j'ai vu d'innombrables cas où presque toutes les mesures connues ne prennent pas en compte quelque chose que je considère comme vital pour la productivité de l'équipe. Donc je déteste généralement ces chiffres durs pour la "productivité". Voici quelques exemples:

  • Lignes de code (LOC) - une mesure généralement détestée, car un programmeur irréfléchi peut générer de nombreuses lignes de code horribles, verbeuses, inefficaces, difficiles à déboguer tandis qu'un bon programmeur crée quelques lignes de code élégantes, faciles à corriger et rarement cassées en plus de temps, mais qui sont globalement un meilleur choix.
  • Bugs générés et/ou temps de correction - tout le monde va générer des bugs, et souvent les bugs les plus chers sont générés par une série de mauvaises décisions pour lesquelles le générateur du problème n'est que le dernier de l'effet domino. De plus, vos grands débogueurs ne sont pas toujours vos grands designers - vous avez besoin des deux.
  • Selon presque toutes les mesures, il y a de grands développeurs qui sont si pénibles à avoir dans une équipe, qu'un développeur "super productif" chassera 10 bons développeurs et je vois rarement quelqu'un qui peut faire tout eh bien, nous aurons donc besoin de plus d'une personne sur le projet.
  • Il n'y a aucun moyen de rendre facilement compte de ces personnes merveilleuses qui voient les problèmes venir avant qu'ils ne les prennent au sérieux et les résolvent, en particulier lorsque le problème est une lacune dans un processus - CM défectueux, construction inefficace, lacune dans les tests, une faille de sécurité - ces ressemblent souvent à une grande perte de temps jusqu'à ce que vous réalisiez qu'ils vous sauvent d'une catastrophe - il n'y a aucun moyen de mesurer cela.
  • De plus, il y a des gens que je considère nécessaires dans une équipe d'une certaine taille que j'appellerais des "bâtisseurs de cohésion" - rarement le sommet absolu de la productivité, ils sont généralement toujours dans les 20% supérieurs et ils font le travail inestimable d'aider à la montée en puissance de nouvelles personnes, en reliant les points et en veillant à ce que les bonnes questions soient posées et que les bonnes personnes soient tenues au courant, ils écrivent (sans le demander!) la pièce clé de la documentation à laquelle tout le monde se réfère car ce n'est pas seulement le bon document, mais il est assemblé de la bonne façon. Si vous voulez que 10 personnes travaillent à une efficacité maximale, 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 n'ai pas encore vu qu'il y en a un qui prend en compte tous ces problèmes, donc je ne suis jamais trop impressionné par des facteurs comme "un bon développeur est 10 fois plus productif qu'un médiocre "parce que je dois me demander si la métrique représente vraiment tout le travail qui doit aller dans un produit continu réussi ou une équipe prospère et prospère.

Donc, ma grande mise en garde est - qu'allez-vous faire avec cette métrique? Je vais utiliser quelque chose comme ça pour être conscient que les bons outils et le bon talent peuvent faire une grande différence dans la façon dont le travail est effectué, mais si vous essayez d'optimiser pour une équipe où chaque individu produit 10 fois la sortie "typique", vous êtes lié pour un cas de frustration. Mieux est de trouver un moyen d'amener votre équipe à faire 2 à 3 fois ce qu'elle faisait auparavant en travaillant mieux ensemble.

20
bethlakshmi

Dans son livre The Leprechauns of Software Engineering , Laurent Bossavit décrit la recherche de la revendication de productivité 10x. Il a découvert qu'il n'y a pas de chiffres solides derrière cela - la revendication est passée de la spéculation au "fait établi" par un jeu téléphonique de revendications successivement plus concrètes en citation. Le billet de blog qui comprend le chapitre sur la revendication 10x, et comprend les citations et les citations erronées pertinentes, est fait et folklore en génie logiciel .

Ce qu'il a trouvé est quelque chose comme ceci: quelqu'un en 1968 a fait une étude comparant les personnes résolvant un problème de débogage particulier, et a constaté que certains l'ont fait 10 fois plus rapidement que d'autres. À partir de cela, nous pourrions conclure que certaines personnes sont 10 fois meilleures à résoudre ce problème , ou nous pourrions conclure que certaines personnes eu de la chance , ou une grande variété de choses différentes. Certaines personnes ont choisi de citer ceci (ce sont toutes des paraphrases) "une étude (Sackman et al, 1968) a trouvé que certains programmeurs travaillent 10 fois plus vite que d'autres". Ensuite, il est devenu "des études ont montré que les bons programmeurs sont 10 fois meilleurs que la moyenne" puis enfin "il est de notoriété publique que la productivité des programmeurs varie de 10 fois entre les individus". Puis quelqu'un recueille toutes ces citations, citant à tort une source originale pour dire "de nombreux chercheurs croient…".

Bien sûr, ce ne serait pas un jeu téléphonique si seule la véracité de l'assertion changeait: le multiplicateur passe à 11 et au-delà aussi.

10
user4051

" Le programmeur productif dans cet environnement est celui qui est le mieux à même de comprendre et de mettre en œuvre les besoins des utilisateurs, pas celui qui peut écrire le code le plus intelligent. "(De Carson630 réponse)

Ce point clé couplé avec les points de bethlakshmi fait un énorme point. Un grand développeur peut être génial dans sa seule tranche de réalité, mais se désagréger dès que le monde change. Être en mesure de répondre aux besoins de l'entreprise est beaucoup plus important qu'autre chose. Au bout du compte, à moins que votre entreprise ne soit de la technologie, l'entreprise ne se soucie pas de la technologie; ils ont besoin de solutions. Donc, être parfait avec les modèles de conception ne signifie pas s'accroupir 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 se trouver un emploi en s'adressant à l'entreprise qui les soutient tandis que les grands développeurs s'ennuient et s'en vont à la recherche d'un défi sans fin. Selon votre organisation et vos projets, il est possible de nourrir ces développeurs affamés de défis, mais il y aura probablement un moment où vous n'aurez tout simplement pas besoin de cette quantité de puissance de traitement. Ces développeurs n'aiment pas rester inactifs comme un processeur. Ils s'arrêteront et redémarreront ailleurs.

Enfin, je dirai que c'est OK de savoir qui sont vos interprètes "clés", mais une "équipe" de développement est toujours une équipe. Pour réitérer 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 les mesures comme celles-ci. Je réaliserais que même le plus petit joueur est toujours une partie importante de l'équipe. Même à 60% moins de la productivité de votre joueur clé, ce joueur peut donner à votre équipe ce dont elle a besoin. Découvrez ce que c'est et essayez de le multiplier. Ne brûlez 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 apprendrez peut-être que ce qui fait un bon programmeur n'est même pas ce programmeur, ce peut être ses pairs, ses opportunités en milieu de travail ou même vous.

2
Draghon