Le demi-cercle (épisode 3 -- Communication Breakdown)

The conclusion seems inescapable that at least with certain kinds of large programs, the continued adaption, modification, and correction of errors in them, is essentially dependent on a certain kind of knowledge possessed by a group of programmers who are closely and continuously connected with them. Peter Naur - Programming as Theory Building

Tu regardes cette partie du code, à laquelle il faut ajouter une nouvelle fonctionnalité, et tu t'entends dire tout haut « Je n'aurais jamais écrit ça de cette façon… Comment peut-on faire un design aussi tordu ? » Jérémie, l'auteur de ce design se trouve à dix pas.  Il est actuellement en train de travailler sur une autre partie du programme, son casque sur les oreilles. Tu pourrais te lever, l'interrompre dans son travail et lui poser des questions, lui faire un retour à propos de ce design. Mais tu te dis « à quoi bon ? » Ce sera au mieux un désaccord de plus, une occasion supplémentaire de mesurer la distance qui vous sépare sur le plan des connaissances, préférences et expérience en matière de design logiciel. Tu te rappelles qu'il y a dix jours il est venu te voir pour t'annoncer qu'il avait décidé de réécrire entièrement le module de communication Front / Back.

- Ah bon !? - Je ne comprends rien à ce qui est fait dans ce module. - Et donc tu veux le réécrire pour mieux comprendre ? - Exactement. - … - Ce sera plus simple. - C'est à tes risques et périls. - C'est OK avec la P.O. J'ai fait une U.S. technique. - Alors c'est OK pour moi. Je ne suis pas en charge de la coordination dans ce projet.

Tu reviens mentalement sur cette conversation. Tu aurais pu insister un peu. Mentionner, par exemple, que tu es ici depuis dix mois, mais qu’il t’en a fallu six avant de pouvoir coder une demande d'évolution sans avoir à demander de l'aide à quatre personnes différentes. Tu te demandes quelles sont les chances que Jérémie reste encore un an sur le projet.

Tu marches dans une pièce obscure encombrée d’un fatras indescriptible. Tout ton travail consiste à tenter de décrire ces obstacles que tu rencontres. Ce n’est certes pas une description très fiable, puisque tu vois principalement avec les mains, les genoux, parfois la tête. Décrire correctement demande de la pondération. Du calme. Comment rester calme quand on se prend continuellement en pleine face des objets non identifiés ? Mais tu crois qu’en les décrivant, tu ménages le temps de tes coéquipiers, puisque tu leur prépares la voie. En quelque sorte.

- J’ai constaté que lorsque l’utilisateur passe par le menu Administration pour établir des autorisations, le template de service n’est pas le même que lorsqu’il saisit l’autorisation au vol pendant la transaction. - Tu veux parler de la transaction 2L ? - Pas la 2L, la 2LB. - Tu m’en diras tant. Bienvenue dans le b… Bon courage! - OK.

Tu pourrais ouvrir ton cahier à n’importe quelle page et intituler cette page : découverte inattendue numéro …

Tu marches dans une pièce obscure, qui n’est pas la même pièce obscure que celle qu’explore Jérémie en ce moment; ni la même que celle de n’importe lequel de tes coéquipiers en fait. Les objets ne sont pas les mêmes; ils n’ont pas la même forme; ils ne sont pas de même nature. Quelles sont nos chances de produire une application cohérente, intègre, robuste dans ces conditions ? Déployés chacun dans sa pièce (est-ce seulement le même bâtiment ?), chacun sur une partie du système, avec quelques outils de survie en milieu obscur, et une bande passante tellement petite que ça en devient ridicule.

Jérémie ne comprend pas cette histoire de bande passante.  Il affirme qu’on n’a jamais eu une fibre aussi puissante. - Je te parle de la bande passante entre nous, pas du réseau. C’est une métaphore. - Je pige pas tes métaphores. Sois plus clair. - Voilà.

Maria, qui est PO/Coordinatrice/Chef de Projet est bien d’accord avec le constat, mais elle dit qu’il faut s’y faire. Ce qui compte, c’est ce que voit le client. Tu te demandes comment le client pourrait voir dans ce système un assemblage cohérent d’éléments conçus pour bien fonctionner ensemble, là où tu ne vois qu’un tas d’objets disparates, un agrégat de trucs disséminés, cristallisés, pour certains fossilisés, et que les vagues technologiques successives ont progressivement accumulé en couches. Tu songes à ce que diraient les clients à propos du temps que demande chaque ticket, s’ils pouvaient voir cette coupe archéologique. Où passe leur budget. Quand on voit le prix des choses. Peut-être bien qu’ils nous diraient :

Pourquoi un champ aussi peu fertile, avec un sous-sol aussi riche ?

« Je ne suis pas en charge de la coordination dans ce projet ». Gna gna gna gna. Mais quelle réponse débile. Bien sûr, que Maria va porter la coordination fonctionnelle et technique de ce projet, assurer sa cohérence interne et externe, et en plus elle va tenir ses délais, économiser, veiller à la bonne humeur sur le plateau, et faire grandir son équipe. C’est certain.

Dix heures trente. Tu passes voir si Audrey et Farid prendraient un café. - C’est pas ma journée, dis-tu. - Qu’est-ce qu’il t’arrive ? demande Audrey - Panne de communication.

Farid sourit et dit: - Oh. Quand c’est comme ça, je me cale dans mon siège pour la journée et je me concentre sur un petit truc bien technique. - En parlant de communication, dit Audrey, je suis allée au Dojo de programmation jeudi dernier. - Comment c'était ? - Pas mal. Un des participants a proposé de faire du Mob Programming. - Connais pas. - C'est comme le Dojo habituel, avec rétro-projecteur et tout, à une différence près. - Laquelle ? - La personne qui est au clavier attend que les participants lui indiquent ce qu'elle doit coder.

Jérémie, qui s'est joint à la conversation, dit en vidant une vieille boule à thé dans la poubelle: - Argh. Je pourrais attendre longtemps..

Farid s'esclaffe. - Sans rire, dit Audrey, il y a même un principe, pour toi, qui aimes bien les principes..

Tu dis: - Ça m'intrigue. Dis m'en plus. - C'est le principe Driver/Navigator. Je ne me souviens plus de la phrase exactement. Mais je l'ai notée.

Vous retournez à vos postes. Audrey ouvre un cahier qui semble aussi rempli que le tien de notes, de listes, et de gros points d'exclamation et de BdMs.

Voilà: Pour aller de la tête de quelqu'un jusqu'à l'ordinateur, toute idée doit passer entre les mains de quelqu'un d'autre.

- Llewellyn Falco.

Et on appelle ça, le modèle Driver-Navigator. Le driver est celui qui est au clavier, les navigateurs sont ceux qui réfléchissent, décident, font le design. Tout le monde travaille sur la même Story, devant un écran.

Hmm.

Driver/Navigator. Driver/Navigator. ...

Tu reviens sur ton bout de code. De toute évidence, ça changerait un peu la vie dans les labyrinthes obscurs. Tu imagines le groupe en action. - Pas par là; il y a une classe entièrement copiée-collée sur la classe TransactionBL. J'ai vu ça la semaine dernière. - Alors contourne, en renommant la classe et en ne gardant que ce qui compte. - Comment savoir ce qui compte ? - Moi je sais ! Va dans le module Livraison. Je peux te montrer. - TransactionBL ? Vraiment ? Il serait temps qu'on se mette d'accord sur les règles de nommage..

Tu fais mentalement la liste des inconvénients possibles d'un tel choix d'organisation. Maria aurait immédiatement un problème de budget, et viendrait vous faire remarquer que c'est très bien de communiquer à propos du code, mais qu'il ne faut pas rêver. Elle qui accuse déjà nos rétrospectives de "cramer du gaz"…

En parlant du loup, voilà Maria qui débarque sur le plateau. Et elle vient te voir directement.

- Comment ça se passe ? - Comme ci, comme ça. Je ne suis pas sûr de finir ce ticket d'ici vendredi. - Ça n'arrange pas mes affaires. J'ai besoin de montrer quelque chose qui marche. - Je pense bien… - Est-ce que tu crois qu'il faut ajouter des ressources au projet ? - Je ne ferais pas ça à ta place… Ajouter des ressources à un projet… - … En retard le met encore plus en retard. Je sais. Brooks. C'est quoi le problème en l'occurrence ? Qu'est-ce qu'il faudrait pour que ce ticket passe comme une lettre à la poste ? - Hum. Revoir l'ensemble du design du produit, et recommencer sur des bases plus saines, avec un standard d'équipe ? - Quand tu seras revenu sur terre, réponds à ma question s'il te plaît, dit Maria en souriant. - Alors, joker. J'ai des problèmes systémiques. - C'est-à-dire ? - Comme quand tu te rends à la conférence sur le réchauffement climatique, et que tu y vas en voiture, tu vois ? - Pas du tout. - À court terme, je peux résoudre ce ticket, mais en créant des problèmes supplémentaires… - Résous le ticket. Pour le reste, on verra plus tard.

De retour dans le code. Dans le code jusqu'au cou. Tu réfléchis à ce que vous pouvez faire. Vous ne pouvez pas réécrire intégralement le système, en décidant et en appliquant des principes agréés par toute l'équipe, cela prendrait des semaines de réunions laborieuses, houleuses, infructueuses.

Englués, chacun dans son dédale obscur, à se cogner dans des trucs. Impossible de produire un travail d'équipe, qui se verrait dans le produit.

Tu notes le principe dans ton cahier. Pour aller de la tête de quelqu'un jusqu'à l'ordinateur, toute idée doit passer entre les mains de quelqu'un d'autre.

Tu notes deux conséquences que tu trouves intéressantes: - De cette manière, vous n'implémenteriez jamais une idée sans l'avoir d'abord communiquée. - De cette manière, vous ne perdriez pas de temps à discuter sur ce qui ne sera pas implémenté.

Tu décides que jeudi prochain, tu iras au Dojo de programmation. Tu retournes à ton écran. Tu enfiles tes écouteurs et tu remets Led Zep', trop fort.

(à suivre) Episodes Précédents : 1 -- Si le code pouvait parler 2 -- Voir / Avancer