La Duck Conf 2024 - Défier l’entropie : Refaire ou remettre sous contrôle ?

Un talk d’Alexandre Jeambrun, 25 ans… d'expérience ! Il a été développeur, chef de projet, architecte,... Il est aujourd’hui consultant, manager référent confirmé, mentor au sein d’OCTO Technology. Il a connu bon nombre de métiers de la tech mais il est avant tout un programmeur dans l’âme et la réponse est en cache: dans la plupart des cas, refaire est voué à l’échec; il vaut mieux remettre sous contrôle !

Vous avez dit entropie ?

“L’entropie est une grandeur physique qui caractérise le degré de désorganisation d'un système.” — Wikipédia

Quelques règles la régissent:

• Toute transformation d’un système se fait avec une augmentation de l’entropie;
• Dans un système isolé, l’entropie est une fonction qui ne diminue pas avec le temps.

Après ce bref rappel plus ou moins douloureux de nos études, Alexandre nous rassure

“On a une chance: nous ne travaillons pas dans un système thermodynamique; nous travaillons dans un système d’information. Donc il est envisageable de maîtriser, si ce n’est de réduire, l’entropie.”

Il identifie alors 3 sources d’entropie dans le monde de la tech:

1. Les humains

C’est la source primaire d’impact sur nos applications. Le mode d’organisation d’une entreprise a, en effet, une influence considérable sur les logiciels qui y sont produits.

Dès lors qu’une décision est prise pour l’équipe, le code sera ainsi impacté, directement ou non, par:

• les activités de management;
• le recrutement;
• les compétences (qu’on a et qu’on n’a pas);
• la gestion du turnover;
• le choix de l’offshoring;
• …

2. La technologie

Angular, React.js, Vue.js, Kafka, rester en Java 3.0, suivre la dernière hype du moment…

“La technologie a une tendance très fâcheuse à changer.”

Quelque soit le choix que l’on fasse, le développement d’une application est constamment exposé:

• aux obsolescences, programmées ou non;
• aux enjeux de sécurité;
• aux besoins de maintenabilité, d’évolutivité, de capacité à délivrer de la valeur en passage à l’échelle;
• …

Cette exposition implique de changer du code et cela amène de l’entropie.

3. L’environnement

• le budget vient de tomber, les finances sont tendues, le marché accueille une startup qui avance comme un bulldozer et qui récolte tous les investissements au grand damn du CODIR, … il faut accélérer la feuille de route
• une nouvelle réglementation vient de tomber (RGPD, RGAA, RGESN, FHIR v5, etc.), il faut ralentir pour se mettre à la page ce qui fait prendre du retard par rapport à la concurrence

Tous ces éléments influent, parfois malgré nous, sur l’entropie du logiciel.

Qui dit entropie, dit complexité

En 1986, Fred Brooks écrit « No Silver Bullet — Essence and Accidents of Software Engineering », un papier qui déconstruit le mythe de la technologie ultime; cette technologie qui aurait raison de tous les problèmes de l’informatique, au même titre qu’une balle en argent peut venir à bout des loup-garous.

Du mythe à la réalité, Brooks fait mention des différentes complexités qui forment l’essence des problèmes:

• La complexité essentielle: c’est les règles de gestion et métier associées au logiciel en développement; elles sont propres et uniques à un contexte donné (administration de réservation, logistique, comptabilité, etc.)
• La complexité technique et collaborative: c’est les moyens techniques nécessaires pour modéliser la réponse aux problèmes que l’on cherche à résoudre et la collaboration pour produire cette réponse. Et qui dit collaboration, dit loi de Conway.
• La complexité accidentelle: c’est ici que nos choix à faire se trouvent et c’est donc ici que réside l’entropie.

Dans le jargon, la complexité accidentelle est communément appelée « dette technique ».

Alexandre souligne à cette occasion que la terminologie de la dette technique est maladroitement utilisée. Elle vient, en effet, du lexique de la finance et elle n’a pas vraiment de sens dans le monde du logiciel. Mais c’est pour une autre histoire.

Quoiqu’il en soit, la complexité accidentelle s’accumule toujours dans les projets, faute de stratégie appropriée pour la juguler, jusqu’à ce que la douleur devienne insupportable.

Par exemple, on ne peut plus livrer en production sans générer pléthore de bugs voire carrément casser la prod’ ou alors cela prend des semaines voire des mois.

Et puis vient la sacro-sainte décision qui se veut salutaire: « Il faut faire une refonte ».

Faire une refonte sans avoir réussi à endiguer les défaillances de la gestion de la dette technique revient en réalité à faire comme les moines copistes au moyen-âge: les copistes copient.

Et par cette action de réplications, un certain nombre de problématiques sont ainsi éludées:

• Quels sont les coûts et les risques d’une telle entreprise ?
• Comment gérer l’ancien système et le nouveau système ?
• Qui fera la maintenance de l’ancien système ?
• Comment faire la migration de l’ancien système vers le nouveau ?
• Quid des données ?
• Comment et où intégrer la nouvelle réglementation pour éviter une amende ?
• ...

“C’est utopique de penser qu’en réécrivant quelque chose de la même manière, on peut obtenir quelque chose de différent.”

Finalement, la refonte implique la multiplication des problèmes.

Heureusement, il existe des moyens de limiter la complexité accidentelle du système sur les 3 sources précitées et ainsi éviter cette situation de refonte quand l’entropie explose.

Source d’entropie #1: les humains

Alexandre propose de reprendre les bases avec le manifeste agile, et plus particulièrement la page des principes qui est moins démocratisée que celle des valeurs:

“Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.” — Agile Manifesto, 2001

Ce postulat de base mène alors à quatre axes pour juguler la complexité accidentelle d'origine humaine:

1. De l’autonomie, de la responsabilisation et de la délégation

Notez que si l’on explique quoi faire au quotidien, on se trouve en fait dans l’acte de déresponsabilisation; on place alors nos collègues dans une posture exécutante voire infantilisante.

“Cela n'a aucun sens d'embaucher des gens intelligents et de leur dire quoi faire; Nous embauchons des gens intelligents pour qu'ils puissent nous dire quoi faire. ” — Steve Jobs

2. De l’espace pour améliorer les pratiques et les compétences

C’est important que les personnes aient de l’espace et donc du temps pour s’améliorer afin d’être en capacité de prendre les décisions qui réduisent le niveau de désordre dans les applications.

3. De la résilience

Le turnover est un non-événement, il doit être prévu dans la stratégie de développement logiciel et de maintenabilité car il est tout à fait naturel pour les individus de vouloir changer, apprendre, avoir de nouvelles envies, projets, etc.

4. Du challenge

Se projeter plus loin vers l’avenir, exprimer sa créativité et apprendre font partie de la pyramide de Maslow, c’est le besoin d’accomplissement de soi ou d’auto-actualisation

Image illustrant la pyramide des besoins selon l'interprétation de la théorie de la motivation du psychologue Abraham Maslow, réalisée par A3nm — Travail personnel, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=91140246

Source d’entropie #2: la technologie

Pour échapper à l’entropie technologique, il faut se mettre en posture d’indifférence aux technologies.

En effet, si mon code métier est mélangé avec le code technologique et que la technologie change / doit changer (pour des raisons de sécurité ou de réglementation, par exemple) alors mon code métier est nécessairement impacté et il faut revalider tout le fonctionnement de l’application. La mise au point peut être douloureuse.

En revanche, si mon métier est isolé de la technologie et que la technologie change / doit changer, il suffit d’adapter le code technologique. Mon code métier n’est pas modifié; le risque de régression fonctionnelle est limité voire nul.

Alexandre relève ainsi quelques axes pour se mettre dans la posture d’indifférence préconisée:

1. Promouvoir une compréhension partagée du problème

Des pratiques comme le Domain-Driven Design (DDD) et l'EventStorming peuvent aider à cela.

“DDD is a philosophy for developing software systems that encourages Domain Thinking at each step of the Software development lifecycle” — Github - ddd-crew/welcome-to-ddd

“EventStorming is the smartest approach to collaborate beyond silo boundaries. The power of EventStorming comes from a diverse multi-disciplined group of people who, together, have a lot of wisdom and knowledge. While it originally was invented for a workshop to model domain-driven design aggregates, it now has a broader spectrum. From gaining a big-picture problem space of the whole domain to gaining insight into the entire software delivery flow and creating a long term planning. Every one of these workshops has the same basic requirements and needs'' — GitHub - ddd-crew/eventstorming-glossary-cheat-sheet

2. Un design en continu et émergent…

… plutôt que l’over-engineering dès les premiers jours de développement ! A t’on vraiment besoin d’une base de données pour assurer la persistance sur un Proof of Concept (POC) ou d’un Minimum Viable Product (MVP) ? d’un cache ? d’une clean architecture aux petits oignons ? de micro-services ? etc.

Ces éléments, certes parfois fondamentaux et nécessaires, sont inutiles avant une première phase de croissance / maturité.

“L’émergence, c’est accepter de ne pas décider tout de suite.”

Il faut identifier et décider le moment où ces briques sont nécessaires et seulement alors passer à leur implémentation et à leur intégration.

3. Modularité

C’est un concept vieux comme l’informatique et pourtant la hype des technologies prend souvent le pas sur cet aspect fondamental. La modularité peut être garantie très simplement en respectant le pattern SOLID et/ou par la mise en place d’une architecture à couplage faible comme l’architecture hexagonale et éventuellement aller plus tard vers une clean architecture

On a d’ailleurs une super vidéo pour en savoir plus sur ces architectures: Comptoir x La Duck Conf - Architecture Hexagonale & Clean architecture bonnet blanc, blanc bonnet ?

4. Refactorer / adapter

“Il faut accepter que le code change; c’est sa nature profonde”

5. Limiter les responsabilités

“Si notre code avait une responsabilité limité, chaque changement aurait une entropie limitée.”

Il faut faire des choses qui font une seule chose et qui la font extrêmement bien; à l’image de ces grille-pains de type “radiateur” sans timers, ni ramasse miette, ni éjection automatique et qui fonctionnent toujours après 50 ans de bons et loyaux services.

Image représentant un grille-pain à volets basculants ajourés, réalisée par Cfrederico — Travail personnel, CC0, https://commons.wikimedia.org/w/index.php?curid=12234074

Source d’entropie #3: l’environnement

Ici règne “l’argent, la valeur, le grisbi” souligne nostalgiquement Alexandre. Et en France, tout du moins, nous avons cette tendance à vouloir amortir l’investissement du logiciel sur trois à cinq ans, un peu comme on pourrait le faire pour toute acquisition de bien.

Amortir un investissement est tout à fait naturel. Mais pourquoi vouloir amortir le coût d’un logiciel sur trois ans ? Pourquoi pas vingt ans ? voire plus ?

Contrairement aux biens matériels, un logiciel ne s’use pas. Maintenir un logiciel longtemps, c’est garder sa valeur dans le temps.

Reprendre le contrôle et le garder

Alexandre ne passe pas par quatre chemins et énonce les éléments de cette démarche à contre-courant:

1. Une application opérationnelle en production

“On travaille sur la route et non sur le côté.”

Si ce n’est pas le cas, il faut ainsi faire le nécessaire pour:

• se remettre sur le chemin, travailler avec la production;
• s'engager à continuer dans ces conditions, coûte que coûte.

On veillera à ne pas faire de branches parallèles qui impliquent les mêmes stratégies de big-bangs et de migrations que l’on a évoqué précédemment.

2. Un filet de sécurité qui repose sur des tests automatisés

Les tests automatisés permettent de prévenir les dégradations.

Notre expérience du terrain nous montre d'ailleurs que les projets sans tests sont les projets qui ont une entropie gigantesque.

3. Des petits incréments livrés très fréquemment en production

Quand on livre très fréquemment, on peut corriger progressivement l’entropie grâce au filet de sécurité et on peut vite se rendre compte si des défauts ont été introduits lors des corrections.

L’étude Accelerate montre que la vitesse induit la stabilité et que la stabilité induit la vitesse.

4. Des mesures

Le métier d’ingénieur est un métier qui repose sur l’empirisme: on mesure pour expérimenter, apprendre et s’améliorer. Il est possible de commencer avec des mesures très simples comme celles de DORA.

Take away

Et si on mesurait le niveau d’entropie potentielle de son application à l’image de l’indice de réparabilité de nos appareils électroniques ?

Il serait calculé sur plusieurs critères, et notamment :

• Le niveau de complexité (accidentelle)
• La quantité de responsabilités et leur découplage
• La dépendance aux technologies
• Le niveau de valeur apporté (Pourquoi conserver quelque chose qui n’a pas de valeur ?)
• L’environnement humain

L’objectif ?

• Lutter contre la dégradation
• Garder longtemps le contrôle de ses applications

Quoiqu’il advienne de cette volonté d’Alexandre, il est possible de maîtriser l’entropie d’une application tout en la changeant.

La réécriture n’est pas la seule issue.