LE SYNDROME DE LA DECHARGE PUBLIQUE

En quelques 350 jours ouvrés de développement sur une même application, j'ai développé une attitude extrémiste et dogmatique quant au maintien de la qualité du logiciel. Je dois en irriter plus d'un dans l'équipe (désolé).

Dans ce billet, je tente de justifier cette attitude. (Le développeur extrémiste a été dévoilé dans le billet UN BON CODE).

LA PETITE HISTOIRE

Avez-vous déjà remarqué que lorsque la décharge publique est fermée, il y a parfois un particulier qui déverse ses détritus devant le portail d'entrée? (voir photo) Avez-vous aussi remarqué qu'une fois qu'un premier "vandale" a ouvert le bal, d'autres suivent son exemple.

"Après tout, l'entrée est déjà souillée, alors c'est pas quelques détritus de plus qui vont changer quelque chose ..."

Parfois même, autres continuent cette dégradation alors même que la décharge a réouvert ses portes!

Ce qui est notable dans ce comportement, c'est que le premier à dégrader l'entrée de la décharge commet l'acte le plus "difficile". Il dégrade un lieu propre. Par contre, il est bien plus aisé pour les suivants de suivre cet exemple en continuant à dégrader le lieu.

Il est aussi notable que si le personnel de la décharge avait immédiatement nettoyé les détritus du premier vandale, les suivants n'auraient probablement pas osé vider leurs détritus devant la porte.

REVENONS A NOS MOUTONS

Ce syndrome se transpose au code d'une application logicielle. Si un premier développeur amorce la dégradation de la qualité du code, par exemple en ne testant pas sa modification, en laissant des warnings de compilation ou en ne respectant pas les standards de l'application, alors d'autres continueront à dégrader l'application.

"Après tout, pourquoi tester ma modification alors que 20% des lignes d'instructions ne sont pas couvertes? Mon code non-testé se noiera dans la masse et passera inaperçu ..."
"Après tout, pourquoi passer du temps à corriger mes 2 warnings de compilation alors que le build en détecte déjà 23?"

Sur plus de 350 jours ouvrés de développement d'un même logiciel, à 25 contributeurs, nous avons remarqué que si la qualité commence à se dégrader, alors le phénomène s'emballe. Il devient alors très difficile et coûteux de l'endiguer et de le résorber. Nous pouvons même autopsier ce phénomène en observant notre courbe d'historique de la non-qualité (voir précédant billet dédié à cette pratique). D'ailleurs, nous utilisons cette même courbe pour détecter l'amorce du phénomène et déclencher les actions correctives.

Il y a une autre raison pour laquelle il faut maintenir l'application propre. Notre build complet publie la liste de la non-qualité détectée. Plus la liste est importante et plus il est difficile pour un développeur d'y retrouver les problèmes liés à son travail. Petit à petit, ce développeur va se lasser de rechercher les défauts qui le concernent directement au milieu de pages de défauts.
Par contre, si la liste des défauts détectés reste très faible, alors chaque développeur y retrouvera immédiatement et très visiblement sa non-qualité. Elle sera si visible que les autres équipiers pourront aussi la repérer. Alors, naturellement, chaque développeur évitera de se faire repérer comme contributeur à la non-qualité en corrigeant au plus tôt ses défauts.

MIEUX VAUT PRÉVENIR QUE GUÉRIR

Ce phénomène me semble très naturel. S'il est n'est pas rigoureusement contenu, l'application va progressivement "pourrir". Il sera alors de plus en plus difficile de faire évoluer le logiciel. Pire, le tas des petits défauts sans conséquence va cacher les bugs dangereux.

Pour palier à ce problème, je pense qu'il est primordial de développer une attitude extrémiste quant à la dégradation de l'application. Ceci est d'autant plus vrai si l'application est volumineuse, si le projet est long, si le nombre de contributeurs est important ou si l'application est critique (notre projet réuni tous ces critères à la fois). Il est judicieux de s'acharner à retirer tous les défauts au plus tôt pour laisser un code propre que personne ne souhaitera dégrader.

POUR ALLER PLUS LOIN

Dans d'autres contextes, ce phénomène et l'attitude appropriée pour l'endiguer sont connus sous le nom Fixing Broken Windows. Ce même phénomène a été transposé au développement de logiciels par les Pragmatic Programmers dans leur article Software Entropy, dans l'entretien Don't Live With Broken Windows et dans leur très bon livre The Pragmatic Programmer.
Bonnes lectures!