Le projet de développement sur lequel vous travaillez actuellement produit subrepticement ou ouvertement ce que tout le monde convient d’appeler de la “dette technique”.

Comment est-ce que je le sais ? Toutes les personnes de ma connaissance qui travaillent dans le développement me parlent de la DT. Tous les projets que j’ai pu approcher, accoster ou prendre en charge dans ma carrière comportaient de la DT.

Ces 20 dernières années, nous avons peaufiné la définition de ce qui se situe à l’ARRIVÉE de la dette technique : une liste de préconisations de corrections à effectuer sur le code, surmontée d’une (grosse) somme en euros.

Nous avons encore beaucoup de mal à décrire ce qui se situe à la SOURCE de la dette technique : un état de l’art qui a perdu peu à peu (ou parfois brutalement) de sa cohérence.

Un ancien collègue me pose cette question :

— Qu’est-ce que tu veux dire par état de l’art ? Dans mon projet, j’ai des user stories, un document d’architecture, quelques diagrammes, je n’ai aucun document qui décrirait notre état de l’art. Ça n’existe pas.
— Est-ce que vous relisez le code ensemble avant de le déployer ?
— Non. On a des pull requests sur le repo directement. Et on ne lit pas ensemble, c’est de la revue asynchrone.
— Vous avez donc un état de l’art.
— Peut être, mais en tout cas on n’a rien d’écrit sur le sujet.
— Ça n’empêche. Est-ce que vous indentez votre code ?
— Bien sûr. En fait, on n’en a jamais parlé.
— C’est inutile : indenter son code fait partie de l’état de l’art quasi-universel des développeurs.

L’état de l’art est l’ensemble des procédés qu’utilisent une personne, une équipe, ou une entreprise, en vue de résoudre un problème imparfaitement défini, dans un contexte incertain. C’est un guide de navigation, qui n’a rien d’absolu. Il n’existe certainement pas un État de l’Art unique, étant donné le nombre de contextes différents dans lesquels on conçoit du logiciel.

Le travail d’une équipe porte simultanément sur le produit qu’elle réalise, sa conception et sur l’état de l’art qui guide cette conception. Au siècle dernier, beaucoup d’entreprises définissaient l’état de l’art des projets une fois pour toutes, avec une faible tolérance pour les initiatives. Aujourd’hui l’entreprise favorise plus volontiers une évolution rapide de l’état de l’art, au risque de perdre en cohérence ce qu’elle a gagné en vitesse d’adaptation.

À moins de travailler tout seul sur un produit très simple, la conception suppose une conversation régulière entre les acteurs à propos de l’état de l’art qui les guide. C’est une exigence à la fois triviale et cruciale, difficile à remplir dans une organisation en silos ou en “factory”.

Lorsque les conversations manquent la dette s’installe.

Imaginez un orchestre de chambre, qui ne se donne plus le la, qui n’est plus en rythme, ne lit plus la même partition, et qui continue à jouer, vaille que vaille.

Quelqu’un dit :

— on reprend ?
— Non, on continue !

publié sur Linked In le 14/02/2023