Tout cela tient au fait que le produit que nous cherchons à réaliser en écrivant du code est un système complexe, opaque, et soumis à la loi des conséquences inattendues. Le code d'une application est un enchevêtrement de ramifications dans lesquelles nos décisions (mais aussi nos élisions, nos erreurs, et nos calembours involontaires) deviennent rapidement invisibles.
Lorsque j'écris un poème, je peux faire une erreur d'orthographe ou un choix de mots médiocre, écrire quelque chose qui sonne creux ou n'évoque rien. C'est (plus ou moins) facile et rapide à détecter. Lorsque qu'on décèle un "bug" dans une application, c'est souvent bien longtemps après que le code ait été écrit ou modifié.
Pourquoi un "bug", et non pas une "poussière", une "boulette" ou une "pétouille" ? Pourquoi le monde des insectes plutôt que celui des arts plastiques ou de la typographie ?
C'est peut-être notre instinct d'éradication qui domine encore ici : face à la complexité — et donc la fragilité — de nos constructions, aucune menace ne sera tolérée. "Je sais pas exactement ce que c'est, mais ça vient de ruiner la démo" : propos de personnes pressées par le temps, et que les projets en retard, coûteux, compliqués rendent légitimement anxieux et furieux.
Puisque les bugs, ces trouble-fêtes, retardent nos projets de manière si remarquablement persistante, peut-être devrions-nous commencer à ralentir et nous mettre à les étudier plus en détail ? Comme celui qui se met à courir sans avoir pris le temps de vérifier ses lacets, si nous traitons de manière précipitée ce qui nous met en retard, nous risquons de nous mettre encore plus en retard.
D'où viennent les bugs ? Certainement pas du code lui-même. Peut-être viennent-ils de notre compréhension du code ? Comme le dit mon ami Fabien Trégan :
Ce qui m'a fasciné lorsque j'ai découvert la programmation, c'est que le bug est forcément dans ma tête, et pas dans la machine.
Et comme le fait remarquer Laurent dans le manifeste du Slow Debug :
Avant de faire des choses dans le monde, regarde d’abord comment est le monde dans ta tête.
En l'occurrence, ce que j'appelle dans ma précipitation un "bug", c'est exactement cela : la différence entre le monde que j'ai dans la tête et le monde dans lequel le comportement du code s'est réalisé et a été observé.
Armés de ces considérations, nous devrions militer — même si je sais qu'il y a des combats plus importants — pour un terme plus approprié en lieu et place du mot "bug". Je propose le terme de retour (feedback).
Un retour, ça a à peu près les mêmes caractéristiques qu'un bug :
- c'est tout aussi vague et difficile à catégoriser a priori,
- ça échappe à notre contrôle par définition,
- souvent, on s'en serait bien passé.
Cependant, contrairement au bug, un retour ne doit pas être éliminé sur le champ, mais au contraire appelle à un temps d'attention.
Un retour entre deux “acteurs” (humains ou non) A et B, c’est une une information émise par A, à propos d'un comportement de B. Voici quelques exemples de bugs dans lesquels on a incontestablement un retour d’information, même s’il est parfois difficile d’identifier A et B :
<em>Segmentation fault : 11
L'application affiche une page 404 parce que j'ai oublié un antislash dans la commande de redirection
Après suppression de la dernière ligne de commande, le montant de la facture passe à NaN -- merci de revoir.
Bonjour, j’aurais une question à propos des règles de gestion concernant la réservation d’une ressource...
Dans la BDD centrale, le nom du champ est ID_PORTEFOLIO et non ID_PORTFOLIO. C'est une erreur qui date de 2014, mais qu'on ne peut pas corriger à court terme étant donné le nombre d'applications impactées.
Dans mon expérience, l'utilisation du mot "bug" dans le contexte de projets en équipe crée plus d'ambiguïtés qu'elle ne permet d'en résoudre.
Je trouve que ce terme contribue à produire une impression générale négative à propos de l'activité de l'équipe, de l'organisation, voire de l'entreprise en général. Comparez cet échange apparemment anodin :
"Dans le backlog du sprint on a 23 bugs, il faut en tenir compte pour l'estimation de l'engagement."
"Oui, mais attention! Ce n'est pas dit que ces 23 tickets soient tous de notre fait."
avec celui ci :
"Dans le backlog du sprint, on a 23 retours, il faut en tenir compte pour l'estimation de l'engagement."
"C'est 10% de plus que dans les sprints précédents. Je propose qu'on réduise d'autant l'engagement pour continuer à traiter les retours correctement."
Au sein de la première équipe, il me semble qu'une partie de l'attention est focalisée sur l'attribution des fautes et la remise en cause des responsabilités. La seconde équipe me semble plus intéressée à exploiter les retours en vue d'apprendre de ses erreurs.
Lorsqu’une équipe se concentre sur le traitement d’une liste de bugs, on dit que le projet est en phase de déverminage. Mais d’une équipe concentrée sur le traitement d’une liste de retours, on ne peut plus dire qu’elle dévermine, seulement qu’elle est en train de prendre en compte les retours. Et comme cela, l’air de rien, on vient de remplacer un processus d’élimination par un processus d’intégration d’une nouvelle information.
En changeant nos mots, on peut changer nos modèles.
Pour aller plus loin :
Référence :
.png)
