Le demi-cercle (épisode 1)
Ça commence par la naïveté, par une sorte d'ignorance bénie. On crée du code sans être conscient des conséquences, et de la nécessité d'un retour d'information sur ce code. On bâtit naïvement une tour, avec ce qu’on trouve ici et là. Quand la tour frémit, on devient soudain extra-prudent, mais alors on prend un peu plus de temps pour chaque chose, et on subit la pression des clients, et du management.
La tour s'écroule; on la remonte, à la hâte. On n'a pas le temps d'assurer la qualité parce qu'on a trop de problèmes imprévus à résoudre parce qu'on a un faible niveau de qualité parce qu'on n'a pas le temps d'assurer la qualité. On perd son calme, on agit de façon précipitée, désordonnée, irrationnelle.
On n'observe pas ce qu'il faudrait, on ne mesure pas les bons phénomènes, et on en tire par conséquent des conclusions fausses, imaginaires. On recherche ce qui cloche en amont, dans les estimations, dans les prérequis, au lieu d'étudier ce qui nous ralentit le plus. On développe une sorte de mauvaise foi, qui sert à tout expliquer. On est sur la défensive.
Pendant ce temps, le code s'enfonce doucement mais sûrement dans l'entropie. Fuite en avant. Pour remédier à ce problème, que faudrait-il faire ? Plus on attend, et plus les contre-mesures sont coûteuses, l'ampleur des travaux impressionne. Observez quelque chose qui subit une désorganisation progressive. La pelote de chargeurs et de rallonges derrière le bureau qui grossit et s'entremêle un peu plus à chaque branchement et débranchement. Une cuisine sale.
Le problème se complexifie avec le temps. On connaît mal les mécanismes régulateurs qui permettraient de résorber ce désordre. Le problème change d'étage : on passe d'un problème de qualité à un problème de résultats, à un problème de crédibilité, à un problème de défensivité. Ça devient une affaire, un conflit, une bataille.
Et quelqu'un lance : "mais si le code pouvait parler, que dirait-il ?"
Alors on essaye de faire parler le code, avec des outils, qui révèlent l'étendue des dégâts, qui calculent la dette technique. Calculer la dette technique, c'est au moins faire quelque chose. C'est comme les congrès sur le réchauffement climatique. Une réflexion sur les conséquences, quand on ne sait pas empêcher les causes. Et pour cause, parce que chaque cause est un micro-détail dans le grand tableau du désastre. Chaque cause demanderait qu'on apprenne un geste nouveau : le geste précis qui évite les futures conséquences.
Le code d'un programme, tel qu'il est présenté dans les livres qui chantent l'Art du Code, est une cathédrale de logique. Mais pour le "noob" fraîchement embauché dans une équipe de "TMA", le code est un champ de mines, un potentiel bourbier. C'est une cacophonie d'effets pervers, de conséquences inattendues dans laquelle les effets composés de chaque décision inconsidérée, de chaque ajout effectué à la hâte, à l'aveugle, à la va-comme-je-te-pousse, se sont multipliés pour former une sorte de bombe logique nucléaire.
Le programme plante. Enchevêtrement de causes multiples.
Le programme plante lors d'un test, ce qui empêche un autre test, lequel test s'il avait lieu révélerait la présence d'un écart entre les résultats actuels et attendus, lequel écart mènerait sinueusement mais sûrement à la détection d'une erreur de logique dans le code qui produit les calculs, erreur qui si elle était discutée entre l'équipe de développeurs et l'équipe de test, montrerait que certaines règles de calcul ne sont pas partagées, sujettes à interprétation, parce que les deux équipes ne voient pas le produit de la même façon.
À chaque étage il y a un détonateur. Que croyez-vous qu'une équipe de professionnels du déminage ferait ? Exactement. C'est exactement le contraire, que fait l'équipe de développement. Personne ne prend le temps de revenir suffisamment en arrière et suffisamment en détail sur ce qui se produit. Au lieu de cela, un développeur est occupé à réparer le programme, pendant que d'autres commentent la situation, ou font du sur-place en attendant une décision du management.
Devant ma logique, celle qui consiste à dire après un incident :
prenons le temps de rétro-analyser, avec rigueur, et sans blâmer, ni décider à la hâte, ce qui a pu se produire, et trouvons des contre-mesures efficaces afin d'éviter des incidents similaires à l'avenir…
…devant ma logique, mes collègues sont perplexes : ça ne ressemble pas à une action qu'on peut mener sans dépenser au moins quatre heures. "Il vaudrait mieux…", "De toutes façons…", "Oui, mais…", et finalement le manager tranche, parce qu'il a le client qui fulmine au bout du fil. "On répare et on re-livre."
Nous vivons dans un monde complexe, et il paraît que le logiciel mange le monde. Et la complexité mange le logiciel. Et le monde, du moins celui dans lequel on démarre, on reprend, on défait, et on relance des projets de développement logiciel, ce monde "surfe" sur la complexité.
Nous recrutons des développeurs et développeuses ninjas, multi-compétents, full-stack serait un plus, ayant le sens de l'aventure, et l'esprit d'équipe, jeunes, des geeks, pour un projet tout-terrain!
Au rythme où vont les projets, il nous faut des équipes toujours plus "tout-terrain".
Comment pourrais-je faire du tout-terrain si je ne maîtrise même pas la conduite du véhicule dans un parking ? Je fais vingt kilomètres, et bim. C'est l'accident bête.
Les gestes de base, on les évoque : "il aurait fallu...", on liste les "best practices", on produit des présentations, et on prescrit des "transformations". Mais on sait parfaitement — puisqu'on serait incapable, comme ça, à brûle-pourpoint, de restaurer un fauteuil Louis XVI, d'exécuter une sonate, ou de dispenser des soins après un pontage coronarien — on sait parfaitement qu'
Il faut dix ans pour faire un expert
… c'est-à-dire que les gestes de base requièrent du temps pour devenir l'habitude, le savoir profondément ancré qui distingue le professionnel de l'amateur même passionné.
Suggérer à une équipe de changer ses habitudes, alors que le projet est en crise ? Avec l'accident au carrefour, on a certes des arguments plus convaincants pour un temps; on a de bien meilleures raisons d'envisager un tel changement, mais changer c'est déjà tellement difficile lorsque tout va bien…
Ce n'est plus le moment d'apprendre les gestes de base.
Si le code pouvait parler, que dirait-il ? Donnons-lui la parole :
Si tu veux comprendre ce que je décris, accroche-toi. Ici je dis la chose comme ci, et là je dis la chose comme ça. C'est comme ça. Je me répète tellement que je peux tuer ton attention, ton intérêt, ton enthousiasme, à longueur de page lue. Je sais, c'est imprononçable, compliqué, tordu, mais attends ce n'est pas tout. Comment ça, est-ce que ça marche ? Est-ce que tu travaillerais dans ce projet si ça ne marchait pas ? Voyons. Vous pouvez faire une mine dégoûtée, c'est comme ça. Essaie de changer cette méthode, rien que pour voir. J'en ai maté des plus durs que toi. Pour fonctionner correctement tout en restant honnêtement maintenable, j'aurais besoin de vingt fois le temps que vous me consacrez actuellement, vous m'entendez, vingt fois. Oubliez vos rêves de simplicité et d'efficacité. Au fond, tu n'es ni un artiste, ni un scientifique, ni un penseur, ni un ingénieur. Tu es un développeur ninja tout-terrain.
Alors on va gérer le retard. On va gérer la dette technique. On va gérer la relation avec le client. Il faut gérer, parce que ça ne se fera pas tout seul. Il n'y a que de la gestion, parce qu'il n'y a pas de solution. Il n'y a pas moyen de faire en sorte qu'un projet en retard ne soit plus en retard. On le sait, mais on va le gérer. Trente-six mois de code propre et qui passe ses tests, c'est déjà une construction très délicate, qui demande de l'attention, tous les jours. Demandez à ceux qui savent. Alors que dire de trente-six mois de code écrit à la rache ? C'est une zone sinistrée pour les années qui viennent. C'est — encore une fois — une bombe logique nucléaire.
Et si c'était le moment où l’on pose son ouvrage et l’on réfléchit ? Si c'était le moment où l'on commence à changer un peu la manière dont on fait les choses ?