Code sale, code propre : faut-il une machine à laver le code dans les équipes ?

« Ton code est sale ! »

Quelle horreur ! Une personne aurait osé écrire quelque chose de répugnant, qu’on devrait toucher du bout des doigts en fronçant les narines d’un air écœuré. Et gare à celui ou celle qui ne participerait pas à ce rituel, se rendant ainsi complice de cette forfaiture extrême !

Assurément, depuis la quinzaine d’années que je code en entreprise, j’ai pu très largement constater que ce comportement est une sorte de rite de passage. Cracher sur le code des autres permet d’affirmer que son propre code est mieux.

Chose amusante : n’est jugé sale que ce qui est le cœur de métier de la personne concernée. Ainsi, le développeur back-end, quand on lui parlera de l’accessibilité de la page web qu’il vient de livrer, parlera plutôt de « contraintes de temps ». Puis il retournera cracher sur le code mal indenté de son collègue.

Ce comportement toxique vient, selon moi, de deux choses fondamentales, que nous développerons ici :

1. la méconnaissance de ce qu’est la Qualité logicielle ;
2. un manque d’attention sur les biais de notre cerveau.

Je pense également que le manque de diversité dans le monde logiciel n’y est pas pour rien. Les mythologies autour des développeurs 10x, la compétence des « ninja », « rockstar », ou simplement la hiérarchisation des développeurs (junior, senior, lead…) n’y sont pas étrangères. Mais c’est une autre histoire…

La qualité logicielle

La qualité logicielle n’est pas un concept subjectif. Largement théorisée depuis les années 70, elle recouvre un certain nombre de domaines, et englobe des aspects qui contribuent au succès d’un projet logiciel, et repose sur des normes et des critères bien définis.

Dès 1976, McCall établit une première classification, qui servira de base pour toute une génération de développeuses et développeurs. Il distingue des facteurs de qualité en trois catégories principales :

Le fonctionnement du produit

• Fiabilité : la capacité du logiciel à fonctionner de manière stable et sans erreurs.
• Efficacité (performance) : l’aptitude du logiciel à exécuter ses tâches rapidement et avec des ressources minimales.
• Intégrité : la garantie que le logiciel protège les données et fonctionne de manière sécurisée.
• Facilité d’emploi (utilisabilité) : l’accessibilité et la convivialité du logiciel pour les utilisateurs et utilisatrices.

Les capacités de changement

• Maintenabilité : la facilité avec laquelle le logiciel peut être modifié ou amélioré.
• Testabilité : la facilité de tester le logiciel pour identifier et résoudre les problèmes.
• Flexibilité : la capacité du logiciel à s’adapter aux changements et aux évolutions futures.

La transition

• Portabilité : la capacité du logiciel à être déployé sur différentes plateformes.
• Réutilisabilité : la possibilité de réutiliser des composants logiciels dans d’autres projets.
• Interopérabilité : la capacité du logiciel à fonctionner de manière transparente avec d’autres systèmes.

Si ce sujet vous intéresse, je me permets de vous conseiller le livre Qualité logicielle pour les développeurs, dont je suis l’auteur, ou tout simplement la page Wikipédia de la norme ISO 9126.

La guerre des priorités

Dans de nombreuses équipes, les querelles de chapelles naissent justement de la priorisation de ces critères de qualité. Chaque membre de l’équipe est attaché à un aspect en particulier, aspect qu’il ou elle considère comme « Le degré ultime de la qualité », ou le plus crucial.

Par exemple, les développeuses et développeurs back-end privilégieront souvent la maintenabilité et l’évolutivité, tandis que les UX (Expérience Utilisateur) défendront l’utilisabilité.

Les Ops (infrastructure) se concentreront, eux, sur la performance et l’efficacité du logiciel.

De la nécessité de faire des choix collectifs

Alors quoi ? Ce serait le rôle de chacun de défendre du mieux qu’il peut ce qui lui semble important ?

Certainement pas ! Dès les années 80, on comprend qu’il faut faire un choix. Il est impossible (et contre-productif) de vouloir combler tous les facteurs. Pire, certains sont incompatibles entre eux (difficile, en général, d’avoir la performance en même temps que la maintenabilité).

Lorsque je coachais des équipes pour leur démarche qualité, je proposais aux équipes, aux décideurs et à toutes les parties prenantes de choisir deux facteurs de qualité très importants, deux facteurs importants et trois facteurs assez importants. Cela a permis d’établir une hiérarchie des priorités.

Il est essentiel de comprendre que seuls les deux facteurs « très importants » doivent être pris en compte au quotidien. Les facteurs « importants » peuvent être mentionnés, mais le reste ne doit pas être une priorité. C’est un moyen de s’assurer que l’équipe se concentre sur ce qui est essentiel pour le projet ou l’entreprise.

Le biais d’achèvement

Une fois que les priorités sont établies, il est nécessaire de faire face au biais cognitif d’intervention (l’expression “completion bias” en anglais est parlante).

Pour résumer ce biais, disons que le cerveau a un besoin de complétude et d’achèvement. Laisser une tâche en suspens rend les personnes mal à l’aise et laisse un goût amer. Tout le monde préfère les choses complètes. Cela nous pousse à essayer de les achever nous-mêmes.

Ce biais a plusieurs conséquences négatives :

• on évite parfois de se lancer sur de vrais sujets, mais on va prioriser les sujets faciles à cocher, même s’ils ont peu de valeur (amis des « todo list », cette étude est pour vous) ;
• on se lance sur des sujets de manière irrationnelle, même sans aucun bénéfice (c’est ce qui nous pousse à nous prononcer sur des projets dont on n’a fondamentalement rien à faire) ;
• on ajoute du stress et de la pression collective pour traiter des sujets, quand bien même ils auraient peu de valeur. Par exemple, on va traiter une anomalie qui survient exceptionnellement pour un seul utilisateur, sur un parcours bien précis et très rare. En réalité, il serait plus logique de laisser le bug tel qu’il est (car extrêmement rare, très complexe à corriger, contournable, etc.).

Or, accepter que certains facteurs de qualité ne seront pas couverts, c’est accepter que ces sujets ne seront pas achevés. Si l’ergonomie n’est pas la priorité du projet, il faut faire du mieux possible, mais il est essentiel d’accepter de s’arrêter à un moment donné et de laisser, par exemple, une interface graphique qui nous semble incomplète.

Cela demande un effort conséquent, qui peut être frustrant, lourd… mais ce n’est pas laisser une chose sale derrière nous. Cette absence d’achèvement n’est ni écœurante ni répugnante. C’est faire un choix éclairé sur les facteurs de qualité prioritaires.

Le biais d’engagement

Un second biais rentre souvent en jeu, et exacerbe les tensions : le biais d’engagement. 

Le biais d’engagement, c’est ce qui, lorsqu’on a attendu le bus deux heures, mais qu’il n’est toujours pas arrivé, nous pousse à persévérer et à continuer à attendre, quand bien même la décision ne serait pas rationnelle. On a investi du temps, de l’argent, et inconsciemment, on ne souhaite pas « perdre » cet investissement, qu’on espère rattraper dans le futur.

Le parieur continuera à parier de manière irrationnelle, et la développeuse ou le développeur qui a commencé à améliorer la qualité d’un aspect du logiciel y consacrera de plus en plus d’énergie, quand bien même ce ne serait pas utile ou bénéfique.

Outre-Atlantique, on désigne ce biais par la « summit fever » (« la fièvre des sommets »), en référence aux décès successifs de grimpeurs du mont Everest depuis 1996. Un psychologue a mis en évidence une obsession aveugle (et irrationnelle) du grimpeur à mal estimer le moment où le sommet sera atteint. Plus le grimpeur s’est investi et est monté haut, plus son estimation de la distance restante est fausse.

Je découvre en écrivant ces lignes qu’un film relate cet événement. Si des lecteurs et des lectrices l’ont vu, n’hésitez pas à préciser en commentaire si le film aborde cet aspect.

Sitôt que l’on s’est investi sur un sujet, notre conviction profonde est renforcée et biaisée. C’est ce qui exacerbe les querelles de chapelles et renforce notre conviction qu’une chose, dans un projet, puisse être sale.

Ces tensions peuvent disparaître

Il est temps d’accepter que, si « sale » il doit y avoir (je préfère l’expression « non conforme »), c’est qu’on l’évalue sur des facteurs collectivement établis, acceptés et connus de tous.

La non-conformité est une norme portant sur des facteurs de qualité, qui doit être explicite et collégiale. Ce qui n’entre pas dans le cadre de ces facteurs ne mérite pas que l’on se batte ou que l’on crée des conflits pour lui.

Développeurs, développeuses, chefs de projet, UX, UI, Ops… acceptez de ne pas vous battre pour du vent. Il n’est pas nécessaire de considérer comme « sale » ce qui n’a pas été priorisé en termes de qualité. Cela vous permettra d’adopter un regard plus bienveillant sur certaines contributions de vos collègues (ou de vous-même).

Acceptez ce goût d’inachevé. Consacrez-vous aux choses importantes pour le projet. Plutôt que de blâmer les autres, focalisez-vous sur la création de la valeur. Renforcez la qualité de ce qui compte, encouragez-la et poussez les autres à faire encore mieux.

Vous verrez : tout le monde passera une journée plus agréable… et le code sera peut-être un peu moins « sale » à vos yeux.