index.md 3.1KB
title: Productivité et folklore
Pour moi le verdict est clair, la prétendue observation « scientifique » sur l’ordre de grandeur des variations de productivité individuelle relève du folklore, des éléments d’opinion non confirmés qui se transmettent et se perpétuent pour des raisons plus culturelles que rationnelles. (Je ne prétends pas qu’il n’y a pas de variations de productivité de cet ordre: je dis simplement que ce « fait » n’est pas démontré, et qu’on ne sait pas quoi en faire.)
L’une des raisons à cela est qu’on n’est pas en mesure de cerner avec assez de précision la notion de « productivité ». A l’origine, on avait tendance à mesurer en lignes de code. Avec le développement de « langages de haut niveau » on a sévèrement remis en cause cette mesure de productivité, puisqu’ils permettaient précisément de faire la même chose en moins de lignes. On a tenté de leur substituer les points de fonction, qui s’avèrent compliqués et peu utilisés par la profession. Mais la vraie question à poser est celles des hypothèses qui sous-tendent la notion de « productivité ».
Par exemple, considérons-nous qu’une productivité ne peut être que positive ou nulle? C’est une hypothèse battue en brèche par la notion de « The Net Negative Producing Programer (cache) »: des membres d’une équipe qui non seulement n’apportent pas une contribution à la productivité mais détruisent celle des autres intervenants.
Faisons-nous la différence entre les efforts et les *résultats* ? Un programmeur peut très bien sembler improductif parce qu’il fournit peu de travail, mais s’il est à l’origine d’une idée innovante qui permet de ne pas coder plusieurs fonctionnalités complexes, sa contribution est d’une grande valeur.
*Folklore ou fait scientifique, comment les différencier* (cache)
Voilà des pistes d’améliorations personnelles :
- réduire les distractions auprès de mes collègues ;
- discuter en amont des développement de leur réelle utilité.
Cette histoire d’itération de retrait me trotte toujours en tête même si je n’ai eu aucun retour pour l’instant.
“You can’t plan if you can’t measure.” This is an idea still taught in business school, it’s a mantra of many managers, and it’s wrong in this context. It assumes everything a developer does is objectively and consistently measurable. As we’ve shown above, there still doesn’t exist a reliable, objective metric of developer productivity. I posit that this problem is unsolved, and will likely remain unsolved.