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](http://www.software-thoughts.com/2009/08/net-negative-producing-programer.html) ([cache](/david/cache/eb1b9ce654fcbfc8ff4bb88df862fa72/)) »: 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.
>
> <cite>*[Folklore ou fait scientifique, comment les différencier](http://blog.institut-agile.fr/2010/11/folklore-ou-fait-scientifique-comment.html)* ([cache](/david/cache/799be21bdc20aa5d5bf8e5b3be3d190e/))</cite>

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](/david/stream/2015/08/24/) 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.
>
> <cite>*[The Myth of Developer Productivity](http://www.dev9.com/article/2015/1/the-myth-of-developer-productivity)* ([cache](/david/cache/1d5da5d83b72ec3e5392d3376c5a1e20/))</cite>