Du management…
Un collègue m’a récemment envoyé un papier de Steven Kerr »On the folly of rewarding A, while hoping for B« . Il montre que très souvent le discours officiel d’une organisation est de vouloir un comportement, tout en mettant en place un système de récompense/punition qui dans les faits pousse les gens à un comportement tout autre, voire opposé. 
Par exemple on demande à un joueur de sport collectif d’avoir « l’esprit d’équipe » et pourtant on ne félicite que les actions individuelles. D’ailleurs, on ne résume un match de football que par les noms des buteurs. Ainsi, agacé qu’un joueur fasse trop de passes à l’adversaire, un entraineur sanctionne chaque passe ratée ; au match suivant personne ne fait plus aucune passe et le jeu est bloqué. 
Exemple parfait de contre-productivité : une clinique veut réduire le nombre de décès. On met donc en place une prime qui doit récompenser le chirurgien qui a moins de X décès dans le mois sur le billard. Que va-t-il se passer ? On peut parier que dans les mois suivants tous les chirurgiens vont toucher la prime… En effet, dès qu’ils s’approchent du quota fatidique, ils repoussent toutes leurs opérations délicates au mois suivant ! Du coup les gens décèdent dans leur lit en attendant l’opération, mais ça n’est pas le problème du médecin. Tout le monde touche sa prime, cependant le nombre de décès global de la clinique augmente…
Cette théorie semble être un grand classique du management (le papier remonte à 1975) mais je n’en avais jamais entendu parler. Et quand je l’ai lu j’ai eu une illumination. Tenez, imaginez que vous vous tenez sur une grande étendue de sable, une sorte de drap rouge à la main ; vous le secouez un peu en vous demandant pourquoi vous avez ça à la main , quand vous entendez un bruit de sabots tagadam-tagadam dans votre dos 
et *vlan*
… au génie logiciel.
J’ai compris beaucoup de choses sur le projet de développement en lisant cela. Finalement, qu’est-ce que l’on demande aux développeurs ? Comportement ‘A’ : « Produire du code de qualité, maintenable par autrui ». Qu’est-ce que l’on récompense ? Les délais de livraison : comportement ‘B’. Je n’ai jamais vu un développeur se faire sanctionner pour du code mal écrit, non commenté ou conçu de traviole. Par contre, prenez du retard sur le développement, vous allez vous faire enguirlander et vous devrez rester tard tous les soirs pour faire bonne figure. Donc, si vous avez envie d’une vie de famille ou de loisirs : bâclez votre code. 
Ne commentez surtout pas, et ne testez que si l’on vous le demande. De toute façon c’est votre successeur qui sera pénalisé par le code non-maintenable ; c’est lui qui ratera ses deadlines 
*niark niak niak niak* (<- rire façon méchant dans James Bond).
Rendre ‘A’ inévitable, récompenser ‘B’
On va pas chasser le naturel, alors on va biaiser un peu. Continuez à récompenser les délais (‘B’), mais considérez ‘A’ comme acquis. Il faut intégrer le contrôle qualité continu et automatisé à tout environement de développement. Il doit être impossible de réussir un « build » (et donc de livrer) si l’artefact en question ne respecte pas tous les standards en vigueur. J’ajouterai même une revue obligatoire de tout code, du stagiaire au chef de projet, avant de pouvoir placer le post-it dans la colonne « fait » du tableau blanc. Passez par la colonne « en revue », ne touchez pas vingt-mille francs. Enfin pas tout de suite… Soyons fous, récompensons la qualité 
.
PS: merci à Majirus pour l’article
C’est-à-dire, tout SAUF un POJO 
!
. L’article propose l’explication que c’est dû à une grande auto-discipline de développeurs, très probablement motivée par l’exposition publique du code source à conjointement au nom de son contributeur.
, cette entreprise 
crise 
réduction des coûts, gel de tout investissement 
