Le demi-cercle (épisode 11 -- boites et flêches)

Tu es super en retard. Tu jette ton sac sous la table et tu démarre ton PC. - Salut ! Je suis super en retard !

Tu salues Jérémie, Audrey, Farid. Audrey dit : - Maria est passée. Elle te cherchait. - Elle a laissé un message ? - Hmm. « J’attends un plan d’action. Je vois rien venir. Je m’inquiète. » - OK.

Pas OK. Ce plan d’action qu’attend Maria, il tourne dans ta tête depuis plus d’une semaine maintenant. Juste des idées trouvées ici et là, rassemblées un peu comme on jette des ingrédients au hasard dans la soupe. Ça macère, sans rien produire de comestible.

Le PC s’allume, et t’informe qu’il va procéder à une mise à jour. Mais je vous en prie, faites. Tu te lèves et te diriges vers le coin-cuisine. En passant devant le bureau d’Audrey tu dis : - C’est pas ma journée. - C’est pas ta semaine, on dirait. Tu as des soucis ? - La routine.

Le coin-cuisine est désert, aubaine inexplicable à cette heure-ci. Explicable, après tout : la machine à café affiche en petites caractères rouges : « ATTENDER ENTRETIEN O_o » Il y a peut-être moyen de se faire un thé. Peut-être que le thé te réveillera aussi bien qu’un café. Tu mets de l’eau à bouillir. Tu lis tes news sur ton réseau social. Scroll. Scroll. Scroll.

Tu reviens à ta place armé d’un gobelet de thé trop chaud et trop petit. Le PC vient juste de terminer sa mise à jour, et maintenant il redémarre. Tu as envie de pleurer. Si on racontait une bonne blague à la place ? - Jérémie, est-ce que tu sais à quoi on voit qu’il y a du software dans une ouvre-boîte ? - L’ouvre-boîte télécharge une mise à jour ? Tu nous l’as faite la semaine dernière.

Maria entre dans le bureau et lance : - Re-bonjour. Quelqu’un a du café lyophilisé ?

Tu devances sa demande suivante : - Je passe te voir dans 10 minutes, Maria. - Impossible. Passe me voir à 14 heures.

Tu ouvres le bug tracker.

numéro : 4243        date : 2017/08/31 statut : en cours    type : bug sévérité : grave     émetteur : C. COURDEL nature : report budgeté partiel résultat incorrect : je passe l’année budgetée, report partiel, option sans dépassement, valide, montant erroné, j’attends 34320 j’obtiens 53896. cf données en pièce jointe prise en charge : _ statut résolution : _

numéro : 4244        date : 2017/08/31 statut : en cours    type : bug sévérité : grave     émetteur : C. COURDEL nature : report budgeté partiel on y est presque description : je passe l’année budgetée, report partiel, option sans dépassement, valide, montant erroné, j’attends 34320 j’obtiens 34000. données idem 4243. prise en charge : _ statut résolution : _

- C’était l’arbre qui cache la forêt. - Hein ? Fait Jérémie. - La 4240. - Tu pourrais me donner un peu plus de contexte ? - La 4240 cachait la 4243 et la 4244. - Je ne te suis pas. - La 4240, c’est une Null Pointer Exception. On corrige, on relivre en recette. Ce qui permet à Claudia de trouver la 4243 et la 4244. D’ailleurs je pense que ce qui se passe dans la 4243 influe sur le résultat qui est indiqué dans la 4244. - Le premier bug a dû altérer la base de données. C’est pour ça que je déteste les bases de données. Les bases de données sont un gigantesque réservoir de variables globales. - Pas de chance, c’est là où nos clients conservent leur précieuses données. - Tu m’en diras tant.

Tu ouvres l’EDI et te plonges dans le code à nouveau, à la rencontre du bug 4243, qui cache sans doute le bug 4244. En te rappelant que ce n’est pas ta journée.

C’est toujours le même désordre, mais ce n’est pas comme si vous pouviez vous y retrouver. Il faudrait prendre des notes détaillées. Faire des croquis, ou des photos, en prenant garde de ne toucher à rien. - Tu es où ? Tu entends la voix de ton coéquipier; il est dans l’immeuble, à coup sûr. Là-bas, au fond de la salle (peut-être) il y a une porte, qui donne sur une autre pièce. Il est là-bas. Tu cries : - Ici. Je suis coincé. C'est trop encombré, je n'avance plus. Assis sur le sol poussiéreux. Coincé. Tu ne sais plus par où tu es entré. Tu ne sais plus ce que tu cherchais. Ah, si, bien sûr. La lumière. - Pas mieux ! Le bruit de vos voix est étouffé par la quantité d'objets qui encombrent (probablement) l'espace. Deux voix dans l'inconnu. Deux agents de contrôle en visite dans le logement d'un locataire malade du syndrome de Diogène. Tout ce désordre accumulé. Tu penses : Si les seules erreurs que nous daignons corriger sont les erreurs de syntaxe, voilà ce qui arrive. Bienvenue dans le désordre ambiant. Pose donc ça là, il reste une petite place. - Combien de temps il faut, tu penses, pour ranger tout ça ? Trois secondes de silence étouffé. - La question c'est plutôt : combien de temps pour sortir de là au plus vite ? Silence. Craquements. Désordre inanimé. Agents de contrôle immobilisés, statut : désemparés. Blip. Fenêtre en bas à droite : Maria: 14h30 plutôt, j’ai un déjeuner.

Un rai de lumière a traversé la pièce, perçant l’épais flux de poussière en suspens pendant une ou deux secondes. Le Plan d’Action, qu’est-ce qu’on fait ? Quatorze trente, ça te laisse très peu de temps pour gamberger encore sur ce plan, ou bien au contraire ça te laisse toute la fin de la matinée plus la pause repas pour trouver une excuse et demander à Maria un peu plus de temps.

Bon.

ToF: Oleg, tu veux m’aider ? Entre midi et 2. Je passe et je ramène les sandwichs ! Oleg : OK pour t’aider, t’embête pas pour les sandwichs on a ce qu’il faut sur place. 12h30.

Vers 13 heures, assis à l’une des tables de l’espace polyvalent qui sert de cantine là où il travaille, Oleg et toi étudiez le fameux plan d’action. Il tient tout entier sur une fiche cartonnée :

Correction des tickets en cours : 80 j Revue de code sur correctifs : 10 j Amélioration du code (dette technique) : 30 j Développement version 4.5 : 120 j

Tout en dégustant ton premier café de la journée, tu expliques : - On réduit l’effort de production de stories de moitié, c’est à dire le périmètre de la version 4.5, et on utilise le temps récupéré pour corriger tous les bugs, et pour nettoyer le code autant qu’on peut. On reste sur un budget de 4 personnes pour trois mois. - Comment est-ce que tu vas convaincre ta direction que c’est la bonne chose à faire ? - C’est là où je sèche, Oleg. - Qu’est-ce qu’il se passe si vous continuez sur votre lancée actuelle, en suivant votre process habituel ? - On corrige les défauts en priorité, et on consacre le reste du temps sur les stories. Mais dans ce cas, on risque d’avoir de plus en plus de défauts, puisqu’on ne fait rien pour réduire les facteurs de défauts. - Qu’est-ce que tu appelles « facteurs de défauts » ? On ne le voit pas dans ton plan. - C’est le niveau de complexité et d’endettement technique du code.

Oleg te regarde sans rien dire. Tu te demandes s’il attend plus d’explications de ta part, s’il réfléchit à ce que tu viens de dire, ou bien si un incident indépendant de sa volonté vient de troubler son attention. Tu optes pour l’hypothèse une. Tu reprends : - Tu es d’accord avec moi, que plus le code est sale, plus la probabilité d’insérer des défauts augmente ? - Peut-être. - Le logiciel pourrit, comme dit l’autre… - Le logiciel est inusable. Pour peu que le support soit toujours utilisable, le logiciel reste absolument intact, tel qu'il a été produit par ses auteurs. - Alors comment expliques tu qu’un logiciel devient de plus en plus coûteux à maintenir ? - C’est sa valeur d’usage qui diminue. Pour la maintenir ou l’augmenter, il faut modifier le logiciel. Si le logiciel est facile à modifier, le coût de maintenance reste faible. - On est d’accord. - Combien de stories sont prévues dans votre nouvelle version ? - 39 - Combien de stories, dans la version précédente ? - 52 - Et dans la version d’avant ? - 60. C’est bien ce qu’on est en train de dire : chaque nouveau trimestre, on produit un peu moins de stories; le coût de maintenance augmente. - Qu’est-ce qui contribue au coût de maintenance ?

Tu regardes Oleg. Cette conversation te semble tourner en rond. Tu demandes : - On peut se faire un deuxième café ? - Bien sûr !

Oleg tourne autour du pot parce qu’il ne peut pas vraiment t’aider. Oleg te fait un cours sur l’économie du développement de logiciel. Oleg se fait l’avocat du diable pour éprouver ton plan et t’aider à l’améliorer. Option 3.

Tout en te commandant un double expresso macchiato, tu énumères : - la complexité du domaine, la complexité technique de la solution, le turn-over, et bien sûr les conditions dans lesquelles on modifie le programme. - Par exemple ? - Par exemple, si je change trois lignes de code au hasard, en m’assurant que ça compile, et que je relivre, je suis à peu près sûr de créer un bug, et donc de rendre la maintenance plus chère, au final. - Donc le process de maintenance lui-même, est un facteur de coût. - Voilà. - Qu’est-ce qui a changé ? - Hein ? - Vous produisez de moins en moins de stories à chaque trimestre, à ce qu’il semble. Qu’est-ce qui varie, parmi les quatres facteurs de coût ? - Je suppose que la complexité du domaine a un tout petit peu augmenté. La complexité technique a augmenté également, à cause de la dette technique. - La dette technique, ça n’existe pas.

Tu reste coi. Oleg est pénible, en fait. Oleg aime bien provoquer. Oleg est en train de réfléchir pour son propre compte.

Oleg poursuit : - Tout le monde parle de dette technique, mais la dette, c’est quand tu dois quelque chose à quelqu’un d’autre, en général, une banque. Les développeurs ne doivent rien à personne. Au contraire, ils sont payés pour faire ce qu’ils font. - C’est une analogie. Ils s’empruntent à eux-mêmes. Ils gagnent du temps qu’ils devront repayer plus tard. - Pas s’ils vont sur un autre projet, ou s’ils se font virer. - Ils détériorent la maintenabilité du code. C’est comme s’ils dégradaient la valeur d’un actif de l’entreprise, en quelque sorte. - Dans l’entreprise où l’on se trouve en ce moment, si quelqu’un s’aperçoit que tu es en train de détériorer du matériel, il ne te laissera pas faire. Ta responsable te laisse dégrader la maintenabilité du code ? - Je dirais qu’elle m’encourage, même. - Alors la maintenabilité du code n’est pas un actif. - Pas pour elle, ni pour la direction, en tout cas. - Donc pas pour toi. - Tu proposes de laisser se dégrader la maintenabilité du code ? - Je ne propose rien. Je pense que tu ne pourras pas convaincre ta direction qu’elle a des actifs à maintenir dont elle n’avait pas connaissance jusqu’ici, et que c’est à cause d’une dégradation de ces actifs que vous allez être en retard, ou que la qualité va se dégrader.

Retour à la case départ. Vous vous rasseyez à la grande table. La salle est presque vide. Oleg sourit. Il demande : - À propos des défauts, qu’est-ce que vous observez ? - En fait, pour chaque nouvelle version, on constate plus de défauts que la précédente. - Donc vous produisez des stories, et des défauts. - En quelque sorte.

Oleg se lève, va fouiller une des étagères au fond de la salle et revient avec une feuille A3 et des marqueurs. - Donc vous passez du temps à coder; ce qui produit : 1) des fonctionnalités 2) des défauts, qui causent 3) des incidents. Plus vous développez, plus il y a de défauts.Lorsque vous avez des incidents, vous cherchez les défauts et les corrigez. Vous passez donc du temps à corriger, ce qui diminue le nombre de défauts. Le temps passé à coder et le temps passé à corriger ne peuvent pas augmenter simultanément : il faut choisir. Ça tombe bien, puisque que quand vous corrigez, vous réduisez le nombre de défauts directement et indirectement puisque vous codez moins. - Pas forcément : il y a des cas où la correction d’un défaut crée un défaut supplémentaire. - Peut-être, mais on devrait essayer de garder un modèle simple… - Mais pas simpliste… - C’est le danger avec les modèles, mais continuons. Si vous ne corrigez pas les défauts aussi vite que vous les produisez, le temps passé à coder des stories va diminuer, au profit du temps passé à corriger des défauts. Comment remédier à cette situation ? - On peut tester le code, ce qui dans ton schéma revient à réduire le nombre de défauts avant que ceux-ci génèrent des incidents. - D’accord. Note que tester prend du temps, et donc diminue le nombre de stories que vous pouvez produire. Là encore, il faut choisir entre les différentes activités. Quoi d’autre ? - On pourrait également prévenir les défauts comme tu dis, en relisant le code systématiquement. Ou en mettant en place du mob programming. - OK. - Oui, mais non, je retire ce que je viens de dire. On essayé les revues, ça prend un temps fou, sans aucun résultat. Et tu sais comment s’est passé notre tentative de mob programming. - OK. Disons que à l’heure actuelle les tests et les revues ne sont pas très efficaces. Donc votre capacité à retirer les défauts est affectée par l'efficacité des tests et des revues. Si ces activités étaient efficaces, elles contribuerait à réduire le nombre de défauts aussi vite que vous les produisez. Mais elles ne sont pas efficaces, et donc si vous les appliquiez, elles prendraient trop de temps. - Voilà. - Mais en améliorant les test et les revues — par exemple en vous formant —, vous pourriez devenir plus efficaces. - Sans doute. - Vous avez donc ces métriques : nombre de stories réalisées, nombre de défauts, nombre d’incidents. - Oui. - Et vous devez répartir votre temps entre : 1) coder des fonctionnalités 2) corriger les défauts constatés 3) tester pour détecter les défauts 4) faire des revues pour prévenir les défauts 5) vous former pour améliorer vos tests 6) vous former pour améliorer vos revues

Bonne chance !

Tu cours pour rattraper le bus, la feuille A3 pliée dans ta poche. Mais ça n’est pas un plan, ça, c’est un modèle. Et plein de ratures encore ! Tu décides qu’on verra bien ce qu’en pense Maria.

(à suivre) Episodes Précédents : 1 -- Si le code pouvait parler 2 -- Voir / Avancer 3 -- Communication Breakdown 4 -- Driver / Navigator 5 -- Brown Bag Lunch 6 -- Conseils à emporter 7 -- Crise / Opportunité 8 -- Le Cinquième Étage 9 -- Que faire ? 10 -- Soit... Soit...