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!

UN BON CODE ...

Dans l'ordre, un bon code

1. passe ses tests avec succès;
2. ne peut être mal utilisé;
3. ne contient pas de redondance;
4. exprime clairement l'intention;
5. est aussi court que possible.

Paraphrase ...
A peu de choses près, les points 1, 3, 4 et 5 sont une citation de Kent Beck, créateur de l'eXtreme-Programming. Praticien de la programmation par contrat, j'y ai rajouté le point 2. (Qu'est-ce que je ne ferai pas pour citer les travaux de Kent Beck et Bertrand Meyer dans le même billet :o)

... néanmoins utile
J'ai la chance de relire beaucoup de code, de binommer avec de nombreux développeurs et d'enseigner. Dans le cadre de ces activités, cette citation en cinq points m'est très utile. Je m'en sers beaucoup et je la cite souvent. Je dois sûrement passer pour un extrémiste dogmatique et têtu ... (Après tout dans un équipe, il est bon d'atteindre un certain ratio développeur extrémiste / développeur laxiste)
N'empêche qu'il y a beaucoup de sagesse empirique dans cette citation. Entre autre, l'ordre des critères est très important.

1. Tu testeras
Les tests occupent le haut du podium. Un code qui n'est pas testé n'a pas de valeur. C'est du code sans garantie. Toute ligne d'instruction doit être couverte par un test. Cela se vérifie très bien avec les outils d'analyse de la couverture structurelle.

2. Tu détromperas
Un code qui ne peut être mal utilisé est un code détrompé. Il contribue à la gestion préventive des défauts dans l'application. La programmation par contrat est une excellente pratique pour détromper le code. Quitte à parler de programmation par contrat, il serait plus exacte de dire: "Un bon code garantie sa postcondition si sa précondition est garantie par son appelant". Pour en savoir plus sur cette pratique rare mais vraiment efficace, vous pouvez lire un précédant billet sur ce sujet.

3. Tu ne te répèteras pas
La duplication est source de défauts multiples et de reprises multiples. Elle nuit à la clarté des intentions. Admettons que j'"hérite" d'un code non testé. Sans hésitation, je préfère consacrer du temps à le tester qu'à en éliminer les redondances. (En fait, j'éliminerai les redondances dès que les tests passeront :o)

4. Tu seras clair et explicite
Le code est bien plus souvent lu qu'écrit - y compris par son auteur! D'ailleurs, l'écrivain est avant tout son propre lecteur. Autant faciliter la vie de tous ces relecteurs. Comme pour le point précédant, je préfère tester que renommer et découper. (Pareil, je renommerai et découperai dès que les tests passeront :o)

5. Tu seras bref
La brièveté du code arrive en dernier car elle peut entrer en conflit avec les points 1, 3 et 4. Dans un tel cas de figure, la brièveté n'est pas prioritaire.
Pour rendre un code testable, il faut souvent créer des interfaces pour injecter des dépendances à la construction des objets. Cela augmente la taille du code. Le test amène également à découper en petites classes et il y a un talon déclaratif à payer pour cette modularité.
Un code sans duplication peut amener à créer une opération pour 2 lignes dupliquées. Au total, en comptant le surcroit de déclaration, cette pratique peut augmenter le nombre de lignes. D'ailleurs, avez vous remarqué que les exemples de code remanié sont TOUJOURS plus longs que leur code d'origine? (voir Clean Code)
Pour rendre un code plus explicite, nous sommes amené à homogénéiser le niveau d'abstraction dans le code des opérations. Pour cela, nous encapsulons le code de niveau d'abstraction inférieur dans une opération. Là encore, nous payons une taxe pour la déclaration des opérations.

Et le code des tests?
Ce codex en 5 règles s'applique au code, mais aussi aux tests, car les tests sont du code. On peut penser qu'il ne faut pas tester les tests sinon on n'en finit jamais. Pourtant, la pratique du Test Driven Developpment issue de l'eXtreme-Programming intègre par construction le test du test!
En effet, lorsque nous commençons par écrire un test qui échoue, puis nous modifions le code jusqu'à ce que le test passe avec succès, nous vérifions la justesse du test. Ce tte démarche en 2 étapes est le test du test.

Un de plus (violation du critère 3!)
Désolé, ceci était le 1379ème billet visant à définir un bon code. Plusieurs livres y consacrent leurs pages. C'est un peu comme les chaînes de chance/malchance. Lorsqu'on lit un de ces billets, on se doit d'en écrire un à son tour ...

RESOUDRE LES PROBLEMES

C'est bien bien sympa de voir les problèmes. Ceci dit, l'objectif reste de les résoudre!

Alors, ces problèmes identifiés et exposés à la vue de tous, sont-ils traités?

1. PETIT RAPPEL

Rappelez-vous: l'équipe prend conscience que pour apprendre, progresser et gagner en efficacité, elle doit résoudre systématiquement les problèmes qu'elle rencontre.
Alors,

• on développe la détection systématique des problèmes;
• on affiche les problèmes pour les rendre visibles;
• on résout les problèmes de manière structurée.

Cette attitude et cette démarche sont décrit dans un précédant billet.

2. EST-CE PRATIQUÉ?

Afin de s'assurer que ces beaux principes sont devenus des pratiques, nous affichons un indicateur révélant le nombre de problèmes résolus (le bas des barres) et le nombre de problèmes non-résolus (le haut des barres). Cet indicateur est actualisé à chaque itération (voir photo ci-dessus).

3. EST-CE EFFICACE?

C'est bien joli de mettre en place de nouvelles pratiques - encore faut-il qu'il y ait un retour sur investissement ... Et là, il faut reconnaître qu'il est difficile de mesurer l'impact de la résolution systématique des problèmes.

Difficile n'est pas impossible: les burndown-chart et la courbe de non-qualité révèlent les gains en productivité et en qualité de cette démarche.
Notamment, la courbe de non-qualité révèle de sévères réductions de la non-qualité correspondant à des chantiers mis en place suite à un problème levé. Ensuite, les paliers qui suivent une chute de cette courbe montrent que l'action corrective "coup de poing" s'est efficacement transformée en pratique continue.
Puisque le burndown-chart ne souffre pas d'une augmentation ou d'une stagnation du "restant à faire", c'est que la résolution du problème a contribué positivement au développement.

4. EFFET SECONDAIRE

Nous avons remarqué un autre effet secondaire bénéfique de cette démarche. Il s'agit d'une très forte augmentation de la standardisation.
En effet, la résolution d'un problème résulte généralement en:

• une contre mesure automatisée (scriptée dans le build, dans le commit, ...);
• une contre mesure manuelle décrite par une petite procédure textuelle;
• l'amélioration d'une procédure existante.

Ainsi, nous avons constaté que notre wiki s'est enrichi de beaucoup de petites procédures pragmatiques. Il s'agit de l'officialisation des meilleures manières de faire à ce moment pour ce projet. Cela constitue un standard léger et évolutif, partagé par les équipiers.

Je pensais que la standardisation étaient une démarche formelle, lourde et ralentissant l'évolution. Je suis désormais convaincu du contraire.

VOIR LES PROBLEMES

"Loin des yeux, loin du cœur". Un problème qui n'est pas visible n'est pas traité.

Sur les conseils de Régis Médina et après avoir assisté à sa conférence présentée à l'Agile Tour à Valence, nous cherchons depuis quelques itérations à rendre nos problèmes visibles pour ne pas les laisser trainer. Pour cela, nous avons mis en place 2 pratiques.

1. VOIR LES DÉFAUTS DU PROCESSUS

La première, déjà évoquée à l'occasion d'un billet sur la résolution systématique des problèmes consiste à afficher sur un tableau dédié les problèmes rencontrés par l'équipe (voir photo).

2. VOIR LES DÉFAUTS DU PRODUIT

La deuxième consiste à identifier, mesurer et afficher quotidiennement et automatiquement la non-qualité du produit. Il s'agit de la somme de tout ce qui est à corriger pour atteindre le niveau de qualité que nous recherchons pour notre produit (et nous sommes TRÈS exigeants).
Ainsi, nous sommons

• le nombre de warnings de compilation du code et des tests,
  
• le nombre d'opérations qui dépassent un seuil de complexité,
  
• le nombre de classes non couvertes à 100% par des tests automatisés,
  
• le nombre de classes qui ne respectent pas les standards de codage ...

L'historique de cette métrique enrichie une courbe qui est affichée quotidiennement à l'endroit le l'open space où il y a le plus de passage, juste à côté des burndown charts.

Depuis que nous avons décidé de rendre visibles ces problèmes, nous nous sommes mis de manière disciplinée et continue à réduire cette non-qualité, comme le révèle la courbe affichée.

Dès que la courbe se stabilise à un niveau acceptable de non-qualité (correspondant à un minimum de travail en cours) nous enrichissons cet indicateur d'une nouvelle classe de défauts. Vous verrez un tel saut commenté à la main sur la courbe affichée. Ainsi, nous relevons notre niveau d'exigence de manière maitrisée.

Nous ne nous intéressons pas à la valeur de la métrique mais plutôt à la pente de la courbe. En effet, elle révèle très clairement si l'équipe s'améliore ou se relâche.

Il est très intéressant d'afficher cette courbe de non-qualité à côté des burndown charts. En effet, on constate souvent que l'amélioration de la productivité (visible sur un burndown chart) se fait au détriment de la qualité (visible sur la courbe de non-qualité). L'affichage quotidien et côte à côte de ces 2 courbes permet de visualiser que nous ne jouons pas aux vases communicants. Mieux, nous arrivons même à corréler que travailler mieux permet de travailler plus vite!

Enfin, nous avons aussi valorisé cette mesure de la non-qualité du produit. A chaque catégorie de défaut identifié nous avons associé une valeur: il s'agit du temps théorique requis pour corriger un défaut de cette catégorie. Ainsi, nous mesurons le temps estimé nécessaire pour obtenir un produit de la qualité recherchée.

Avec la mesure quotidienne et combinée du restant à faire et de la non-qualité du produit, nous avons des outils objectifs, pertinents et complémentaires pour piloter notre développement.

RECRUTE EQUIPIER

Nous cherchons un équipier pour un CDD d'un an. Si vous êtes mobile pour venir sur Valence et que vous souhaitez intégrer un grand projet industriel, cette opportunité pourrait vous intéresser.

Sincèrement, je pense que notre projet est une bonne école du génie logiciel. Nous exigeons un niveau de qualité maximal, convaincus que bien développer le bon produit permet de développer plus vite. Nous pratiquons l'eXtreme-Programming, Scrum, le Lean, la démarche orientée objet et la programmation par contrat.

Si vous êtes tentés par cette aventure enrichissante techniquement et humainement, l'offre est accessible via l'APEC ici. Si vous voulez en savoir plus sur notre équipe, on en parle sur d'autres blogs, tels celui d'Alexandre Boutin.

A bientôt?

THE TOYOTA WAY, JEFFREY K. LIKER

Après avoir lu plusieurs livres sur le Lean appliqué au développement logiciel, tels Lean Software Strategies, Implementing Lean Software Development et Lean Software Development, j'ai eu besoin de pousser plus loin ma compréhension de cette philosophie pour aider à sa pratique sur notre projet.
En insistant que le Lean s'apprenait par la pratique avec un mentor praticien et non dans les livres, Régis Médina m'a tout de même conseillé la lecture de The Toyota Way.

Le Toyota Way est la philosophie de gestion pratiquée par Toyota. Elle est structurée en 4 parties: la philosophie à long terme, le processus, collaborateurs et partenaires et la résolution des problèmes.

Nos années de pratique de l'eXtreme Programming, de Scrum et du Lean Software Development nous ont conduit à mettre l'accent sur l'aspect processus du Lean. Notre pratique s'appuie essentiellement sur les nombreux outils du Lean, tels le flux continu, le kanban, le jidoka, les andon, le heijunka, le management visuel, etc. Le dernier billet de Régis Médina révèle que nous ne représentons pas un cas isolé.

La lecture du Toyota Way nous a permis de comprendre que nous avions - non pas négligé - mais plutôt sous-estimé - les 3 autres facettes: la philosophie à long terme, les collaborateurs et les partenaires et la résolution des problèmes.

En réaction, nous sommes actuellement en train de travailler sur la résolution des problèmes. Sur ce thème, nous travaillons actuellement sur plusieurs axes en parallèle:

1. Rendre visibles les problèmes de l'équipe (voir billet);
   
2. Mettre en place une résolution systématique et structurée des problèmes (voir billet) ;
3. Animer régulièrement des chantiers d'amélioration de type Kaizen (billet à venir!);
4. Avec des praticiens qui enseignent le métier, pratiquer un leadership de terrain (billet à venir!).

A bientôt pour les billets annoncés!

AGILE TOUR 2009 VALENCE - C'EST FINI!

Cette année, pour l'édition 2009 de l'Agile Tour à Valence, nous avons reçu 150 participants représentant un peu plus de 40 organisations. Grâce aux intervenants et aux sponsors, nous avons accueilli plus de monde que l'année dernière autour du thème du développement agile.
Quelques blogueurs parlent de l'évènement, tout comme:

• Emmanuel Hugonnet,
• Alexandre Boutin et
• Florian Villoing.

Les présentations sont consultables en ligne sur le site du CARA.

En assistant à des conférences, on ramène toujours au moins une piste à explorer. Cette année, notre équipe à déjà commencé à mettre en pratique plusieurs idées recoltées à l'Agile Tour Valence:

• Rendre visibles les problèmes de l'équipe. Je consacrerai un billet à ce seul sujet.
• Valoriser la dette technique: de manière automatisée, la partie visible de la dette technique du projet est mesurée, puis estimée en heures de correction.
• Nos pratiques de résolution systématique des problèmes et d'amélioration continue n'ont pas toujours un impact visible sur nos indicateurs d'avancement (burndown et vélocité). Une explication consiste à conclure que ces pratiques sont inefficaces. Une autre explication consiste à supposer que notre panel d'indicateurs est inapproprié pour détecter l'effet de ces améliorations. Nous avons alors complété nos indicateurs de pilotages par 2 métriques révélant l'efficacité de nos pratiques d'amélioration continue. Je consacrerai également un billet à ce seul sujet.

A bientôt pour le détail de nos nouvelles pratiques.