La Dette Technique #6 : un état de l’art désaligné

Stabilité du code

Le code Forth écrit sur mon C64 il y a 40 ans "marche" encore. Lancer ce code aujourd'hui sur une telle machine me serait difficile, coûteux (et inutile), mais ce code, lui, n'a pas bougé. C'est tout le reste qui a changé.

De même pour le code que nous avons déployé en production il y a 3 mois. Il ne subit aucune altération, et pour peu que nous sachions comment le redéployer via un plan de secours, il est en sécurité.

Tout le reste va changer

Voici ce que nous allons découvrir :

• un nombre indéterminé mais fini d'oublis, de distractions, de contresens, de calembours, d'erreurs de type et autres pointeurs nuls, qui mesurera en partie l'écart entre la réalité du comportement du système tel que nous l'observons et l'idée que nous nous en faisons
• certaines des règles qui déterminent le comportement du code sont incomplètes, contradictoires ou incohérentes avec ce que nous croyions avoir conçu correctement, en accord avec le Métier et le Management
• sa structure nous semblait adéquate pour l'objectif Métier tel que nous le comprenions, mais un nouveau pan fonctionnel, dévoilé il y a peu en comité de pilotage, nous fait dire que des remaniements importants seront nécessaires
• la seule personne qui militait (oui, c'est le mot, dans beaucoup d'équipes, il faut militer pour cette cause) pour qu'on écrive des tests automatisés sur la partie middleware, quitte le projet, et nous ne savons pas si l'état de l'art de l'équipe - et donc de la future version du code - sera maintenu
• notre optimisme - cette maladie professionnelle - va à nouveau buter sur le constat que ce programme, ce projet, sont plus complexes qu'ils en avaient l'air initialement, lors du chiffrage

Et nous appellerons cela, de la Dette Technique.

Nous continuerons à prêcher pour une méthodo plus Agile, un delivery plus Craft, mais sans quitter nos modèles et sans nous poser la question cruciale :

Comment se fait-il qu'un projet cadré le 2 Janvier par une équipe soudée, cohérente et dynamique, produise au 30 Septembre une dette technique aussi élevée ?

La dette technique est la cristallisation d'un état de l'art désaligné qui, depuis le code, nous parle des contraintes, des objectifs, et de l'équipe au sens large.

La contre-mesure consiste à réaligner votre état de l'art : faire en sorte que les objectifs, les contraintes et l'ensemble des procédés qui constituent le standard du projet soient mieux alignés et plus cohérents. C'est un travail compliqué, assez peu technique. Pour "désendetter" il faut certes un menu Refactor, mais il faut aussi et avant tout des conversations.

Dans un modèle de développement vu comme un processus de fabrication, la dette technique culmine, parce que dans ce modèle on essaie de limiter le nombre et la durée des conversations.

Dans un modèle de développement vu comme un processus de traduction, il en va autrement.

‍