Il y a quelques mois de cela, Michel vous parlait de la culture du Software Craftsmanship. Il évoquait notamment dans son article les différents enjeux à adresser pour diffuser cette culture dans l’entreprise. J’aimerais prolonger son discours en vous proposant de revenir sur l’origine de cet océan de code “legacy” dans lequel beaucoup d’entres nous naviguent douloureusement chaque jour. Mais surtout, j’aimerais vous proposer des moyens de s’en sortir.
Oui, nous sommes entourés de code pourri, au sens propre du terme. Il s’est altéré au point d’être inutilisable, il est maintenant impropre à la programmation, à l’évolution. Pourquoi ? Parce qu’il n’a pas été entretenu, un peu comme une maison qui aurait été laissée à l’abandon.
Comme le disait Michel, la mauvaise qualité de ce code a plusieurs conséquences :
Quand le code est vraiment mauvais, on peut même assister à un désengagement des développeurs. Or, nous savons aujourd’hui que les 20% de turn over de l’industrie informatique sont essentiellement liés à leur degré de satisfaction et d’engagement. Et à chaque départ, bien souvent, c’est une partie (parfois bien trop grande) de la connaissance du système d’information qui s’en va…
Nous avons une conviction chez OCTO : le développement est un savoir-faire, qui s’acquiert via l’expérience et l’accompagnement de ses pairs, comme dans tous les artisanats. Or, même si tous les développeurs (se) sont formés à la programmation, bien peu l’ont été aux pratiques de développement essentielles que sont, selon nous, la revue de code et l’écriture de tests unitaires automatisés (ne parlons même pas de TDD). D’autant plus qu’une formation n’est pas suffisante : comme leur nom l’indique, les pratiques de développement nécessitent de la pratique pour être ancrées au quotidien.
Ce manque de formation et de pratique fait que bien peu de développeurs sont capables de mettre en place les tests unitaires et la revue de code dès le démarrage d’un projet, ce qui va vite s’avérer nuisible. Ainsi, l’existence de code pourri peut avoir 2 effets :
Il est donc nécessaire de former et d’accompagner les développeurs aux pratiques de développement, mais aussi de leur donner le temps de pratiquer au quotidien. En effet, en plus d’assurer le bon fonctionnement de son application, ces pratiques coûtent moins cher sur le long terme à l’entreprise !
C’est indéniable, les pratiques de qualité logicielle font qu’une fonctionnalité prendra plus de temps à être développée. Mais par contre, elle mettra moins de temps à être mise en production. Ainsi une étude réalisée chez Microsoft sur l’impact de TDD leur a permis de montrer que pour un temps de développement supérieur situé entre 15 et 35%, on obtient une réduction de la densité de bugs par ligne de code située entre 60 et 90%. Si on estime qu’un développeur ne faisant pas de TU passe 50% de son temps à faire du debug, dans le pire des cas (35% de temps supplémentaire pour “seulement une réduction du nombre de bug de 60%), en faisant le postulat que tous les bugs prennent le même temps à être corrigés, on peut obtenir le graphe suivant :
On voit donc apparaitre un gain de temps de l’ordre de 25% ! Et on ne parle même pas des gains en qualité et maintenabilité induite par le développement en TDD du code. Ces gains qui feront gagner du temps lors des prochaines évolutions du code.
De même, une étude universitaire a permis de montrer que la mise en place de revues de code permet de réduire jusqu'à 5 fois la quantité de bug livrée en production, notamment si celles-ci possèdent un bon niveau de discussion entre les développeurs. En ce qui concerne le ROI de la pratique, on l’estime à 4 pour 1.
Qui plus est, les pratiques de qualité ont pour vertu essentielle de prévenir ou de détecter pendant la phase de construction les défauts de l’application. Or, il ne faut pas oublier la loi du defect cost increase : plus un bug est détecté tardivement, plus il coûte cher à être corrigé.
Ces données nous montrent donc que mettre en place des pratiques de qualité dans le cadre du développement fait gagner du temps et économiser de l’argent.
Dans ce genre de cas, 3 options s’offrent à moi si je suis un décideur :
Il va sans dire que chez OCTO, nous vous conseillons la troisième solution. Mais comment faire ? Nous proposons une démarche progressive pour l’acquisition d’une pratique, en suivant une règle de 3 : 3 jours pour se former, 3 semaines pour que ça devienne un automatisme, 3 mois pour obtenir un ROI (qualité obtenue sur temps investi).
Nous travaillons donc de la manière suivante avec nos clients pour accompagner une équipe de développement :
Et si vous ne deviez commencer que par un ensemble de pratiques limité, nous vous conseillons fortement de commencer par TDD et la revue de code : ils offrent un ROI rapide et un gain de qualité important pour les équipes qui travaillaient sans jusqu’alors.
Vous avez déjà mis en place un certain nombre de ces pratiques mais vous ne constatez pas le gain en qualité espéré ? Nous vous invitons à (faire ?) auditer vos pratiques via des interviews. Ce qui vous permettra de savoir si celles-ci n’ont pas été mal comprises ou détournées de leurs buts initials. De même, inspectez votre code pour comprendre les problèmes que celui-ci traverse.
De plus, n’oubliez pas de mesurer un avant et un après. Vos mesures seront les meilleurs avocats concernant la mise en place de pratiques de qualités. Voici quelques exemples de mesures intéressantes à suivre : le nombre d’anomalie par fonctionnalités/User Story, le nombre d’anomalies détéctées avant une MEP/une livraison, le nombre d’anomalies corrigées avant une MEP/une livraison.
En conclusion, je voudrais revenir aussi sur une cause malheureusement très courante des problèmes de qualité : la loi de Conway. Votre code est pourri tout simplement parce que personne ne vous a jamais donné les moyens d’en faire quelque chose de qualité. J’espère alors que les quelques arguments que j’ai pu vous donner au sein de cet article vous permettront de défendre votre point de vue et de changer les choses… Bon courage !