La danseuse et la dette technique

Une "danseuse", dans l'expression héritée du XIXè siècle, désignait une maîtresse qu'on entretient à grand frais, et par extension un projet, une habitude auxquels on consacre une dépense excessive pour des raisons largement affectives et peu utilitaires.

L'expression m'est revenue à l'esprit en réfléchissant à une conversation récente sur la "dette technique", le terme consacré pour désigner des logiciels dont le code source est mal fichu, à tel point qu'ils deviennent de plus en plus difficiles à faire évoluer. J'ai connu des projets de ce type, et j'ai été frappé de leur côté "danseuse": ce sont des projets sur lesquels on investit beaucoup d'argent, mais dont on retire très peu de profit; pourtant on ne se résigne pas à s'en séparer.

L'une des difficultés est que les conséquences de la "dette technique" se font sentir de façon très tangible, mais la "dette" elle-même n'est pas visible, on ne sait pas la mesurer. Dès lors il est difficile de justifier des décisions radicales, puisqu'elles vont s'appuyer non pas sur des éléments objectifs mais sur le ressenti des développeurs. "La dette technique est trop élevée, on ne peut plus continuer!" - "Ah bon, à combien la chiffrez-vous?" - "Euh... on ne sait pas... mais c'est trop."

Surgit alors une idée: pouvons-nous trouver des outils d'analyse du code qui vont nous permettre de mesurer la dette technique? Idée lumineuse sur le papier: non seulement elle va nous permettre d'objectiver quelque chose de flou et subjectif, mais en plus nous pourrions installer de tels outils dès le début du projet et ainsi éviter la dérive de la dette, en conserver le contrôle en permanence.

Malheureusement, je crains que cette idée ne soit un miroir aux alouettes. Ce n'est pas que de tels outils soient inutiles; mais s'appuyer exclusivement sur eux révèle une incompréhension majeure de ce qu'est la dette technique, en présence de laquelle leurs résulats seront inexploitables. Pour résumer en quelques mots, la dette technique n'est pas dans le code, elle est entre le code et ceux qui l'entretiennent. Pour bien expliquer cette thèse je vais devoir faire intervenir... une autre danseuse.

L'autre danseuse

Regardez bien l'image animée ci-dessous.

Dans quel sens voyez-vous tourner la danseuse? De la gauche vers la droite, ou l'inverse? Dans un cas comme dans l'autre, si vous continuez à vous concentrer sur l'image pendant un moment, il y a de grandes chances pour que vous voyez ce sens de rotation s'inverser subitement, un effet visuel qui perturbe un peu: on se persuaderait facilement qu'il y a tromperie quelque part, que c'est l'image qui a changé et pas simplement notre perception de l'image. (Je connais des gens qui après avoir vu cette image ont passé un temps considérable à l'analyser avec Photoshop pour trouver "l'astuce". Il n'y a pas d'astuce.)

La réalité est que cette animation fait partie de la même catégorie d'illusions d'optique que le fameux cube de Necker, celle des images ambigues. L'effet de silhouette supprime de l'image toutes les informations liées à la profondeur, et met sur un même plan tous les éléments d'anatomie, bras, jambes, cheveux, de sorte qu'il n'est tout simplement pas possible de savoir quel sens de rotation est "réellement" indiqué par l'image.

Pourtant notre cerveau insiste: il ne peut pas tolérer l'ambiguité, il est donc obligatoire de voir la danseuse tourner dans un sens ou dans l'autre. Nous avons la sensation irréfutable que le mouvement est dans l'image, pas dans notre esprit.

Projection

Cette sensation correspond à une classe de phénomènes cognitifs appelés "projection". Une projection, de manière générale, est une opinion ou une croyance qui ne regarde que nous mais que nous interprètons comme une réalité extérieure.

Par exemple si je me promène le soir dans un quartier qui a une réputation "chaude", je ressens de l'inquiétude, et puis je vois arriver deux personnes qui parlent fort, je me dis "Ces gars-là ont l'air vachement aggressifs, sûrement des voyous" et m'enfuis en courant devant deux passants tout à fait normaux mais médusés...

Localiser la "dette technique" seulement dans le logiciel relève de la projection. En fait la dette technique est un concept intrinsèquement relationnel, c'est un rapport entre des gens (une équipe de développement par exemple) et une collection d'artefacts logiciels dont du code source. La question qui se pose est "quels freins ces personnes rencontrent-elles quand elles cherchent à intervenir sur ce logiciel", est-ce qu'elles trouvent leur chemin, est-ce qu'elles sont forcés à du travail inutile, etc.


Bonne dette, mauvaise dette...

Par exemple on dit qu'un des éléments majeurs de la dette technique c'est la duplication de code. Mais si on y réfléchit plus précisément, on se dit que le code est toujours dupliqué en plein d'endroits: chaque programmeur en a une copie intégrale, grâce à la gestion de versions! Et ça ne gêne personne, ce n'est pas de la dette, parce que l'outil gère très bien cette duplication. Donc il y a de la duplication qui n'est PAS de la dette technique. C'est comme le cholestérol en somme, il y a le bon et le mauvais...

La mauvaise duplication par exemple, c'est quand d'autres programmeurs ont fait du copier-coller et que le taux de TVA à 18,6% se retrouve partout dans le code. Quand il passe à 19,6%, ça prend plus de temps de faire une recherche et un remplacement globals que si on pouvait simplement modifier le chiffre à un endroit unique dans le code. Et imaginez qu'en plus du copier-coller il y a des programmeurs qui ont écrit 0,186 à un endroit, 18,6 à un autre, 1,186 à un troisième: des variantes multiples qui font que rechercher-remplacer ne marche pas.

La dette technique est faite de difficultés de ce type, des ruptures entre le modèle métier et son expression dans le code, ou bien des hypothèses non explicitées qui ne se révèlent que quand elles changent, et on se retrouve coincé: mais on se retrouve coincé par rapport aux outils dont on dispose ou par rapport à un niveau de compétence ou par rapport à un état de connaissances de l'équipe.



La dette est dans l'interaction
 
Il n'y a pas dans l'absolu de dette technique dans le code. Pour mesurer la dette, il faut penser en termes d'observation des interactions entre les gens et le code.

On peut réfléchir à des métriques "objectives" telles que la complexité cyclomatique, mais ce qui est déterminant c'est la façon dont l'esprit humain appréhende le code pour le modifier, et ce qu'il faut donc expliciter, c'est ce que ces métriques peuvent avoir comme relation avec l'exécution par le programmeur des tâches courantes. Or c'est un sujet largement ignoré; la faute à notre tendance fâcheuse à la projection...