Depuis que je suis dans le logiciel, on parle du développeur 10x. Ce sont les personnes que vous voulez pour résoudre vos problèmes ; ils le feront en 1/10e du temps, avec 1/10e du nombre de lignes de code. Ils semblent géniaux.
Mais d’où vient ce terme ? Est-ce qu’ils existent ? Et même s’ils existent, voudriez-vous en être un de toute façon ?
Tom DeMarco et Tim Lister ont, depuis 1977, mené les « Coding War Games ». Il s’agit d’une enquête publique sur la productivité dans laquelle des équipes d’implémenteurs de logiciels de différentes organisations s’affrontent pour réaliser une série de repères en un minimum de temps avec un minimum de défauts. Ils ont fait participer plus de 600 développeurs.
Qu’ont-ils appris ?
- Le choix du langage de programmation a eu peu d’impact – que ce soit COBOL/Fortran ou un langage de haut niveau comme Pascal, la dispersion des résultats est à peu près la même. La seule exception était le langage d’assemblage.
- Il n’y avait pas de corrélation entre l’expérience et la performance, sauf que ceux qui avaient moins de six mois d’expérience avec un langage ne réussissaient pas aussi bien que les autres.
- Les développeurs de solutions zéro défaut ne payaient aucune pénalité de performance pour faire un travail plus précis (en fait, ils prenaient légèrement moins de temps !).
Ils ont cependant constaté qu’il y avait d’énormes différences entre les organisations. La meilleure organisation travaillait 11,1 fois plus vite que la pire. De plus, ceux qui ont travaillé le plus vite ont développé un code qui a passé le test d’acceptation. Affaire classée ?
Et bien, pas tout à fait. L’étude établit ensuite une corrélation entre l’environnement de travail (qui est différent selon les organisations) et les performances. Il s’avère que le groupe disposant d’un espace de travail calme, privé et dédié a obtenu des performances significativement meilleures.
La leçon apprise – mettez d’abord en place votre environnement de travail avant de commencer à vous inquiéter de savoir si vous pouvez trouver 10x des développeurs ou non !
Le programmeur producteur négatif net
Schulmeyer observe que certains développeurs sont des « programmeurs producteurs négatifs nets » (NNPP), c’est-à-dire qu’ils produisent tellement de défauts que les retirer de l’équipe augmente la productivité. C’est presque le contraire du développeur 10x – il est possible d’avoir quelqu’un dans l’équipe qui la rend pire.
Si les producteurs négatifs existent (- Nx développeurs ?) alors il est clairement possible d’avoir un développeur 10x (mathématiques mises à part).
Ce n’est pas le meilleur argument pour le programmeur 10x cependant, n’est-ce pas ? Si je demandais à un écolier de rejoindre une équipe, serait-il un producteur net négatif ? Probablement, si je les laisse s’asseoir dans un coin et taper du code (et si d’une manière ou d’une autre ils peuvent passer à la production !) Si vous êtes le genre d’entreprise qui laisse les gens s’asseoir dans un coin, ne donne pas de feedback et les laisse pousser à la production alors je pense que vous méritez probablement d’avoir des NNPP dans votre équipe !
De façon plus réaliste, j’espère que dans toute entreprise normale, si vous employez quelqu’un, vous allez lui donner tout le soutien dont il a besoin pour être génial dans son rôle (revue de code par les pairs, feedback, un mentor, analyse de code automatisée pour le feedback, matériel d’apprentissage, etc.)
Je suppose qu’il est toujours possible que vous vous retrouviez avec un NNPP mais je soupçonne que c’est très peu probable. Cela ne semble certainement pas être la meilleure histoire pour l’existence de développeurs 10x.
Etudes expérimentales exploratoires comparant les performances de programmation en ligne et hors ligne
Sackman, Erikson, Grant ont publié un article en 1968 intitulé « Études expérimentales exploratoires comparant les performances de programmation en ligne et hors ligne ». L’une des citations à la fin porte sur les différences individuelles et les études « ont révélé de grandes différences individuelles entre les performances élevées et faibles, souvent d’un ordre de grandeur ». Serait-ce le papier magique qui décrit cette différence de 10x ?
Il est utile de lire l’étude entière et de mettre un peu de contexte autour de cela. Tout d’abord, ces tests comparaient à la fois les performances au stylo et sur papier ainsi qu’en ligne en utilisant un IBM AN/FSQ-32. Les programmeurs écrivaient leur code (soit sur un stylo/papier à donner à un opérateur, soit directement dans l’ordinateur) en utilisant un langage appelé JTS (un dérivé d’ALGOL).
Ils avaient deux tâches à résoudre, la première consistait à interpréter des équations algébriques avec une seule variable dépendante. On leur a donné le papier de Samelson et Bauer pour les aider à mettre en œuvre la solution. Une image tirée du document est présentée ci-dessous :
La deuxième tâche consistait à résoudre un labyrinthe 20×20 qui a exactement un chemin. Le labyrinthe était décrit par une table de consultation de 400 éléments où chaque entrée contenait des informations sur les sorties de chaque cellule. Aucun matériel de support n’a été fourni pour ce défi. La résolution de labyrinthes est un espace de problèmes fascinant et je suppose que ceux qui avaient suivi récemment un cours de théorie des graphes avaient un gros avantage !
Connaissant ces tâches, je ne suis pas surpris qu’il y ait de grandes différences individuelles. En 1968, le génie logiciel venait tout juste de naître en tant que discipline. Les tâches sont de nature mathématique et on ne sait pas très bien quels étaient les antécédents des participants. Cela favoriserait certainement ceux qui ont suivi des cours de mathématiques de niveau supérieur.
Je pense que la personne 10x que vous trouverez à partir de cela est douée pour résoudre ces problèmes. Je peux croire que dans l’espace problème de « résoudre un labyrinthe + équations linéaires » il peut y avoir un développeur 10x, mais il est difficile que cela se transfère à tout autre domaine.
Dois-je être un développeur 10x ?
Probablement. Mais probablement 10x meilleur pour écrire du code.
Il y a une bien meilleure discussion des méthodologies de recherche derrière le mythe du développeur 10x dans cet excellent livre. Même si un développeur 10x existe, vous ne devriez probablement pas aspirer à en être un ; même si vous pouvez implémenter le code parfaitement du premier coup, vous découvrirez probablement que vous résolviez le mauvais problème en premier lieu.
Même si ces études étaient vraies, le génie logiciel a évolué (au moins dans mon domaine de développement de produits).
Auparavant, nous pouvions faire une seule grosse version par an, avoir quelques exigences et passer l’année à les implémenter. Cela a évolué vers une approche agile où il y a un cycle continu d’élicitation, d’imagination, de mise en œuvre et de vérification. Dans ce modèle, la mise en œuvre n’est pas (généralement) le goulot d’étranglement
Une heure gagnée au niveau du non-boulot d’étranglement est un mirage. (Eliyahu Goldratt)
Alors que devez-vous faire à la place ? Eh bien, concentrez-vous sur le fait d’être plus précieux pour votre entreprise. Pouvez-vous :
- Identifier les problèmes précieux pour votre entreprise ?
- Concevoir une solution que les gens peuvent utiliser ?
- Recueillir des commentaires pour évaluer si elle est précieuse ?
- Écrire un logiciel qui fait une réelle différence pour de vraies personnes ?
- Fixez-vous sur les vrais problèmes plutôt que sur ce qui est intéressant ?
- Faites grandir les membres de l’équipe pour qu’ils soient géniaux ?
Et un million et une choses qui ont plus de valeur que d’écrire un code parfait en un temps record (voir en forme de t !).
Ce n’est pas pour dire que le codage n’est pas important. Le codage est important ! Le code est lu 4x plus qu’il n’est écrit, donc si vous écrivez du code facile à raisonner, alors cela rapporte énormément à l’avenir (il y a peut-être une histoire de 10x là-dedans quelque part, mais je laisserai cela pour un autre jour). Investir du temps dans votre métier (qu’il s’agisse de codage ou de conception ou de gestion de projet) est une nécessité, mais rappelez-vous simplement que votre métier n’existe pas de manière isolée et qu’il existe pour servir un objectif plus élevé.
Ne vous concentrez pas seulement sur le fait d’être le meilleur développeur du monde, concentrez-vous sur la situation dans son ensemble (rappelez-vous Product over Project !). Apprenez un large ensemble de compétences (en particulier celles qui sont liées aux personnes) et vous serez beaucoup plus précieux et beaucoup plus proche d’un véritable « développeur » 10x.
.