Le mur de la dette

Il faut aller vite, prouver qu'il y a un marché, acquérir des premiers utilisateurs, les garder, lever des fonds, délivrer, délivrer. Alors forcément, l'équipe tech ne va jamais assez vite. Alors on a passé le POC en prod. Aïe. Et le modèle qui ne tient plus… on n'a pas les bons objets métier, mais le refacto est gigantesque. Et puis l'upgrade Typescript, on a 2 versions majeures de retard. Mais il faut délivrer. On n'a pas de test d'intégration, on fait ça à la main et ça prend un temps fou. Mais on n'a pas le temps parce qu'il faut délivrer.

Ça vous semble familier ?

C'est vrai que la pression du business favorise l'apparition de la dette technique. En même temps, cela fait partie de notre métier à nous, développeurs et développeuses, de faire avec cette pression. C'est notre lot commun. En tant que professionnels du code, il est de notre responsabilité de délivrer sans compromis sur la qualité. Nous n'avons pas à demander l'autorisation de bien faire notre travail. À nous de dire "non" quand il le faut, et c'est une compétence à part entière !

Mais avant cela, produire du code de qualité, ça s'apprend. C'est un ensemble de considérations méthodologiques et architecturales que l'on regroupe sous le terme d'artisanat logiciel (Software craftsmanship) : Clean code, Test-driven development, programmation fonctionnelle, you name it. S'y former prend du temps, des années (une vie ?).

Mais la dette n'est pas qu'une affaire de compétence technique. Il y a aussi la connaissance du métier. Quand on ne maîtrise pas suffisamment le métier, on va tout droit vers des problèmes de nommage et de modularisation. Le code que l'on écrit est inutilement compliqué parce que l'on n'a pas fait émerger les bonnes abstractions, celles qui sont significatives d'un point de vue métier. Si vous venez de penser "Domain-driven design" (DDD), c'est normal 😉

Mais parfois, même si l'on maîtrise son sujet, on prend sciemment des raccourcis dans le code, pour satisfaire un impératif de calendrier. Est-ce mal ? Pas nécessairement : bien utilisée, une petite quantité de dette peut s'avérer bénéfique. Par contre, ne pas la rembourser, c'est mal. Pas bien. Rappelez-vous :

"Un crédit vous engage et doit être remboursé. Vérifiez vos capacités de remboursement avant de vous engager."

Après, une fois que le mal est fait, c'est plus compliqué, car la dette appelle la dette (ce qui signe une croissance exponentielle 😱). En effet, même avec la meilleure volonté du monde, il est difficile de construire proprement sur des bases qui ne sont pas saines. Et puis, c'est humain, il nous est difficile d'échapper à la théorie de la vitre brisée.

Allez, je vous rassure, la dette ne s'explique pas que par nos errements de pauvres pécheurs. Non, elle provient aussi de l'inadéquation du code à un instant donné par rapport à ce que l'on veut en faire, c'est-à-dire par rapport aux nouvelles fonctionnalités que l'on souhaite implémenter. L'entreprise s'adapte au marché, à ses utilisateurs, le besoin émerge et le code se retrouve en tension.

La dette ne résulte donc pas nécessairement de mauvaises décisions. On peut en limiter l'apparition par de bons principes d'architecture (modularisation, architecture hexagonale), mais elle reste pour ainsi dire inévitable. Écrire du code, c'est déjà… créer de la dette. Bienvenue dans la vie 🥲

Le grand problème, c'est que le code — comme la finance — est invisible. Tant que l'on est dans le début de l'exponentielle, la dette peut s'accumuler dans un silence relatif, jusqu'au jour où elle se fait remarquer. Et là, on frappe le mur.

Le mur de la dette, c'est un peu comme le mur du marathon (*) : on fournit 2 fois plus d'effort et on va 2 fois moins vite. Les entreprises sont nombreuses qui embauchent frénétiquement mais voient leur vélocité décroître.

Dur, dur.

Cette problématique est caractéristique des scale-up, c'est-à-dire des start-up qui ont trouvé leur marché et rentrent en phase d'expansion. Ce qui marchait bien à 6 personnes (notamment les schémas de communication) ne fonctionne plus à 20 et encore moins à 200. L'industrialisation est la grande problématique des scale-up. Or le code est beaucoup un sujet d'organisation et de communication entre humains, comme l'a souligné Martin Fowler dans cet aphorisme désormais célèbre :

"N'importe qui peut écrire du code compréhensible par un ordinateur. Les bons programmeurs écrivent du code que les humains peuvent comprendre."

Une start-up aura donc tout intérêt à se pencher sur ces sujets que l'on regroupe sous le terme un peu générique de qualité de code dès les premières lignes afin de contrôler sa dette technique. Et pour les autres… c'est là que j'interviens 😁.

Bon, mais quand la dette s'est installée, que faire ?

Eh bien il n'y a "que" 2 choses à faire (les guillemets s'imposent) :

1. Arrêter d'en créer, autant que possible, dès que possible. Ce qui veut dire se former et mettre en place de nouveaux standards partagés au sein de l'équipe. Quelques mois suffisent par exemple pour s'initier au Test-driven development et s'en servir au quotidien pour écrire le cœur de métier. Témoignages disponibles sur demande 👌

2. Résorber la dette existante. C'est un travail de longue haleine, qui demande une bonne priorisation, de vraies compétences de refactoring et avant cela une très bonne compréhension du domaine. Car quand on parle de re-modularisation (on en parle 1 fois sur 1), les réponses sont à rechercher dans le domaine. Hashtag #DDD.

Enfin, avant cela, le plus dur est encore de reconnaître l'existence du problème. Mais ça, nous y reviendrons une autre fois.

À la semaine prochaine 👋 !

(*) Ceci n'est que le début d'une longue suite de métaphores plus ou moins hasardeuses sur la course à pied, qui me permettront de placer tôt ou tard que je cours le marathon en 2h38.