Citations

Loading Quotes...

Espérer le comportement ‘A’ tout en récompensant ‘B’

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é. :roll: 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é. :pinch:

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 :wassat: , quand vous entendez un bruit de sabots tagadam-tagadam dans votre dos :unsure: et *vlan* :pinch:

… 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. :devil: 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 :D *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é :alien: .

PS: merci à Majirus pour l’article

ohmerde4j

Alors, prenons le prochain ticket d’incident… voilà. bla bla bla… :| mmmh. OK. Ça doit pas être bien compliqué ça devrait se trouver quelque part dans cette classe, là. Tiens, je l’ai jamais ouverte celle-là. Allons-y, Ctrl+Shift+T, OK, de quoi ça a l’air ? 8O Oh meeerde

C’est précisément l’effet « rôh merde » qu’essaie de mesurer l’outil Crap4j, via la métrique CRAP (Change Risk Analysis and Predictions), ou bien, en français, l’ohmerditude. Cette traduction en vaut une autre, et puis j’aime bien le suffixe « -itude » :D .

Ce qui me plaît dans cette métrique, c’est que, pour une fois, on part de la question avant de parler de chiffres. Je n’aime pas l’approche qui consiste à constituer des tableaux de chiffres sans fin, qui certes donnent un air très savant, mais qu’on est bien en peine d’exploiter :roll: . A travers l’ohmerditude, dans le but de vérifier qu’un code est maintenable, on essaie de répondre à la question « un développeur va-t’il trouver risqué de modifier ce code lors d’une maintenance ? ». Si oui, on prend le risque que personne ne touche plus à ce code qu’entre deux doigts, le bras tendu et en se pinçant le nez de l’autre main (voir fig. 2 ;-) ). Les développeurs vont ajouter tout autour de cette boîte noire des couches et des couches de rustines et contournements de moins en moins maintenables :cry: .

:idea: Maintenant que vous touchez du doigt tout l’intérêt potentiel de cette métrique, intéressons-nous à son calcul. La formule est un dosage pifométrique de complexité cyclomatique et de couverture de tests. En gros, un code sera « crappy » (ou « ohmerdique » si vous préférez) si il est (1) très complexe et (2) très peu testé. Un code très simple sans test ou un code complexe mais très bien testé seront considérés comme acceptables.

Crap4j mélange donc le nombre de conditions à tester avec la couverture de lignes des tests… mmmmh. :| bon, on a vu pire. Plus exactement, Crap utilise le taux de lignes non couvertes. Si l’on pose l’hypothèse que les décisions sont uniformément réparties dans les lignes de code, alors cette mesure serait une sorte d’estimation de la quantité de décisions non testées. Malheureusement je ne connais pas d’éléments qui viendraient confirmer cette hypothèse, et ça serait quand même peu fiable.

Quel usage ?

Prise en tant que métrique isolée, cette mesure ne serait pas passionnante. Par contre, je l’utiliserais comme indicateur de testabilité et de possibilité de changement. Selon l’ISO-9126, testability et changeability sont bien des sous-caractéristiques de maintainability, on est bien en élément de réponse à la question initiale. Et comme la norme laisse complètement libre la façon de calculer des indicateurs pour les sous-caractéristiques qualité (ce qui est la façon normative de dire « démerdez-vous on vous donnera pas la formule »), Crap peut être utilisé comme formule de calcul de testabilité « sur étagère », qui présente l’avantage d’être simple à expliquer, rapide à mettre en oeuvre et déjà outillée.

A condition que vous n’ayez pas déjà d’outil de mesure qualité qui vous permette de consolider différentes mesures, et à condition également de calibrer crap4j en fonction de vos exigences, celui-ci peut constituer un premier niveau d’outillage qui vous incitera peut-être à aller plus loin.

On préférera peut-être la version produisant des rapports (via ant, à intégrer à son build continu, donc) que la version plug-in eclipse : le public visé pour cet indicateur de risque qu’un changement soit non testé me semble plutôt le gestionnaire (chef de projet par exemple) que le développeur, qui va probablement garder sous les yeux dans son IDE des règles de codage plus immédiatement « actionnables ».