Le demi-cercle (épisode 8 -- Le cinquième étage)

The treatment of error as a source of valuable information is precisely what distinguishes the feedback (error-controlled) system from its less capable predecessors. -- Jerry Weinberg

@OlegTxl Direct Message

salut Oleg tu aurais une heure à m’accorder ?

ok, vers 18h? ping moi

Ping

pong

Merci Oleg. J’aimerais un conseil à propos de mob prog pour mon projet au boulot

OK

on m’a donné 3 mois pour changer la situation sur l’appli dont je m'occupe

situation == ?

On doit livrer une version majeure dans 3 mois

Mais on rencontre plein de soucis liés à des pb de qualité.

Ma responsable me demande d’améliorer la qualité

c’est quel genre de pb ?

Un peu de tt, mais surtt design et des régressions, mais tt n’est pas du bug

Le pense que les users essaient de faire passer des évol en douce

combien de personnes travaillent sur cette app ?

4. Ma resp est aussi PO. Tu crois qu’il faut recruter ?

si tu veux passer les 3 prochains mois à former une nouvelle recrue, oui

Bon je pense également que ca sert à rien

J’ai envie de proposer de faire du mob, mais si ça marche pas ?

de quels moyens tu disposes ?

A moi de définir

Dans les limites du raisonnable

Ce que j’aimerais c’est trouver le moyen d’avoir - de bugs

on peut se parler de vive voix ? Ou au tél ?

je t’appelle

- Qu’est-ce que tu appelles un “bug” exactement ? - Bonne question ! Une tâche imprévue qui se glisse dans ton travail… - C’est vague… - Disons qu’on a des incidents en production, liés à des erreurs. C’est moins vague ? - Donc un “incident”, c’est un problème qui concerne l’application ou l’utilisateur ou le système, ou éventuellement la documentation ? - Tu veux dire l’absence de documentation, plutôt. Mais oui c’est ça. - Et une erreur ? - Une erreur c’est quand il y a un défaut dans le programme, ou les données. Mais parfois on nous renvoie des défauts qui n’en sont pas. - Et qu’est-ce que ça change ? - Je comprends pas ta question. - Ok. Ce n’est pas grave. Est-ce que vous distinguez les incidents des défauts dans votre suivi ? - Non on a tout dans le même outil. On crée seulement des incidents. Pourquoi ? - Pour comprendre ce que vous faites de l’information. - Quelle information ? - L’information qui se trouve dans les incidents et les défauts. - Je ne te suis pas. - Les incidents et les défauts sont une source d’informations, à propos de votre produit, et de votre process; tu es d’accord ? - Je suis d’accord, mais qu’est-ce tu penses qu’il faut faire à partir des incidents ? - Je dirais qu’il y a 3 choses à faire avec les incidents. Primo : gérer l’incident et trouver le défaut qui est -- peut-être -- à l'origine de l'incident (évidemment). - Bien sûr. - Deuxio : créer un système pour mieux détecter les défauts, par exemple, des tests. - Par exemple. - Et trois : créer un système pour prévenir les défauts, c’est-à-dire pour les empêcher. Parce que la meilleure stratégie de gestion des défauts, c’est de ne pas en produire en premier lieu. - Tu en as de bonnes. - N’est-ce pas ? - Tu veux dire que mob programming est une pratique de prévention des défauts ? - Pourquoi pas ? On peut le voir comme ça. Pourquoi on se mettrait à plusieurs pour produire du code que l’on pourrait programmer tout seul, si ce n’est pour trouver plus rapidement les défauts ? - Tu pourrais m’aider à mettre ça en place ici ? - Mec, j’ai pas le temps ! - C'est dommage. - Oui. - Ok, ce serait quoi, ta meilleure idée ? - Je t’ai déjà donné ma meilleure idée. - Hein ? - 1 : gère les incidents, 2 : détecte les défauts, 3 : préviens les défauts. - Du coup c’est un peu abstrait, comme conseil. - A quel niveau vous vous situez dans ces trois activités là où tu travailles ? - Je pense que pour gérer les incidents on sait à peu près faire, tests: on pourrait largement s’améliorer, quant à la prévention on a pour ainsi dire aucune de stratégie. Il y a du boulot.

- Je te propose de jouer à un petit jeu de rôle. Dans ce jeu de rôle, imagine que tu es un très jeune développeur juste sorti de l’école. - OK. - Tu viens juste d’être embauché dans une entreprise qui a l’air de très bien marcher. Tu as intégré une équipe de trois personnes, et on t’a confié la maintenance d’un programme existant qui fait des calculs compliqués pour une des directions métier. - OK. Ça a l’air cool.

- Tu es au premier étage. Étage 1. - Étage 1 ? D’accord. - Sylvia, une utilisatrice du programme en question vient d’avoir une mauvaise surprise : elle obtient un résultat incorrect sur un des calculs : 70.000 au lieu de 140.000. Du simple au double. Qu’est-ce que tu fais ? - Je fais une copie des données et je cherche à reproduire le défaut dans mon environnement.

- Bravo. Tu es maintenant à l’étage 2. - C’était facile. - Tu as trouvé l’origine du problème: c’est une typo dans un nom de variable. L'auteur du code avait écrit « prefit » au lieu de « profit ». Il se trouve que le programme est écrit en Awk, langage dans lequel on ne déclare pas les variables. Lorsque Awk interprète une variable qu'il ne connaît pas, il la crée et l'initialise à zéro. C'est pratique parce que ça permet d'écrire des programmes très concis. Mais c'est aussi un problème, parce qu’en cas de typo, ton programme continue avec une valeur à zéro sans signaler aucune erreur. - Je vois. - Qu'est-ce que tu fais ? - Je change de langage ! - Tu n'as pas des semaines devant toi. Il faut agir tout de suite. Qu'est-ce que tu fais ? - Je corrige le problème, et je livre une nouvelle version. C’était juste une typo.

- Bien. Tu es maintenant à l'étage 3. - Parfait. - Parfait, pas tant que ça: Sylvia vient te voir pour te demander s’il y aurait un moyen d’éviter ces erreurs de calcul à l’avenir, parce que ça fait mauvaise impression… - Ouch. - Qu’est-ce que tu fais ? - Je passe des tests sur le programme avant chaque nouvelle livraison ?

-  Bravo. Te voilà au quatrième étage ! Maintenant tu lances des tests systématiques sur ton programme avant de le livrer. Tu es encore loin de le tester intégralement, et de toutes façons tu sais que ce n’est pas possible, mais tu fais tout de même quelques trouvailles intéressantes : d'abord, un des résultats n’était pas bien présenté, le format avec séparateur de milliers n’était pas respecté. il y a une autre erreur de calcul, liée à une autre typo : tu as confondu deux variables (dont les noms étaient assez proches, remarque). et aussi une erreur de logique : dans un cas un peu spécial, l’algorithme ne va pas jusqu’au bout du calcul, parce qu’il boucle sur lui même. et enfin, en faisant tourner ton programme sur un fichier volumineux, tu t’aperçois que le temps d’exécution passe de 4,32 secondes pour 100 lignes à 1 heure 20 pour 10.000 lignes. - Ouah. - Qu’est-ce que tu fais ? - Euh. Je cherche un autre job ? - Vraiment ? - Je corrige tous ces problèmes, et je relivre. - C’est bien. Tu es toujours à l’étage 4. Sylvia a signalé ces problèmes à Harold, son manager. C’est normal, vu que ses résultats dépendent de ton programme, et que Harold lui demande des comptes. - Argh… - Tu es donc invité (ou plutôt convoqué) par Harold. Harold te demande : jusque là on est plutôt satisfait, mais à l’avenir est-ce qu’il y aurait un moyen de répondre un peu plus vite à nos demandes ? Une semaine de recette pour un programme de quelques lignes, c’est un peu fort de café ! - Hmmm. - Qu’est-ce que tu fais ? - Je lui dis : je voudrais bien t’y voir ! - Sérieusement, qu’est-ce-que tu fais ? - Je demande à mes coéquipiers s’ils peuvent m’aider en relisant le code avec moi.

- Très bien. Te voici à l'étage 5. Tu organise des relectures systématiques sur ton programme. Ça prend un peu de temps, mais on ne trouve pratiquement plus de défaut en production. Et en plus il y a quelques avantages collatéraux : Ton équipe connaît suffisamment le code du programme pour t’aider à le faire évoluer ; comme il s’agit d’un domaine un peu complexe, ça t’aide beaucoup ; Et vous avez un standard de code, qui est alimenté à chaque revue ; Sur un total de 5 revues vous avez déjà trouvé : 2 autres typos sur des noms de variables (eh oui) ; 3 erreurs de logique assez subtiles ; une douzaine d’améliorations de la présentation du code ; une nouvelle façon de générer automatiquement des données de test. - La vie est belle ! - Oui. Harold te convoque à nouveau. - Ah bon ? - Il te dit : maintenant que tout marche comme sur des roulettes, on se demandait si tu pouvais te libérer un peu de temps pour un autre petit programme, mais vite fait, bien fait, tu vois, avec un process un peu plus lightweight que votre process habituel. - Oh là… - Qu’est-ce que tu fais ? - Je lui dis non. - Tu ne peux pas vraiment dire non à Harold. Qu’est-ce que tu fais ? - J’essaie de lui montrer qu’il vaut mieux suivre le nouveau process. - Très bien. Comment tu fais ? - J’imagine qu’il suffit de comparer les résultats que j’avais à l’étage 1 avec ceux que j’obtiens à l’étage 5… - Quels résultats ? Ce qui intéresse Harold, c’est les chiffres. - Je dirais, pour chaque étage, je montre le nombre de défauts trouvés en production; le temps passé à prévenir les défauts; le temps passé à corriger des défauts. Et après avoir comparé les étages, il décide de me laisser appliquer mon process plutôt que le sien. - Voilà. Et tu restes au cinquième au lieu de revenir au premier étage. - Je vois. - Toute la question c’est : à quel rythme veux-tu passer du premier étage au cinquième étage ? - Justement, est-ce que c'est applicable à ma situation ? En trois mois ? J’ai comme un doute. - Tu m'as demandé ma meilleure idée ; c'est ma meilleure idée. - Je t’offre une bière pour te remercier. - Merci, mais une autre fois, je n’ai vraiment pas le temps. - Au fait : qu’est-ce qui se passe au 6ème étage ? - Au 6ème étage, tu deviens manager. - Et ça consiste en quoi ? - Tu aides tes équipes à gravir les étages.

(à 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é