L’état de l’art d’un projet perd inéluctablement de sa cohérence au cours du temps, car celle-ci est fortement liée au contexte.

L’application de vente en ligne mentionnée précédemment en est un exemple. Un projet aux objectifs relativement modestes, dans un contexte incertain, met en œuvre une gestion de données simple basée sur la technologie ISAM. 5 ans plus tard, l’application est en succès; ses fonctionnalités évoluent, ainsi que son modèle de données. Il est plus que temps de remplacer cette technologie par un SGBDR, lequel offrirait :

  • de meilleures abstractions pour traduire le domaine métier vers le modèle relationnel
  • un langage de consultation et de mise à jour puissant et robuste : SQL
  • des contraintes d’intégrité fonctionnelle gérées en quelques déclarations (plutôt qu’en dizaines de pages de code)
  • des performances d’accès similaires à celles du séquentiel indexé

Ce changement, évident pour les acteurs Techniques, représente un coût inacceptable pour le Métier. Quand au Management, il est devant un choix :

  1. imposer au Métier de revoir ses objectifs à la baisse
  2. négocier la transition vers le SGBDR, en présentant au Métier les avantages à en retirer
  3. temporiser, c’est à dire attendre de voir si ce désalignement pourrait se dissiper de lui-même

Avec l’option 3, l’organisation crée de la dette sans rien faire : celle-ci augmente naturellement avec le nombre de fonctionnalités et de données nouvelles créées pendant que la technologie reste inchangée.

Quelques fois le temps n’y est pour rien : l’état de l’art initial d’un projet peut être incohérent dès le départ. C’est le cas lorsqu’une équipe se donne pour objectif de coder et de mettre en production un design complexe sans l’aide d’aucun procédé de prévention des défauts tels que la relecture de code, ou les tests automatisés, et décide de s’appuyer seulement sur un procédé de type essai / erreur, lequel convient assez bien pour des projets simples.

Une équipe qui, interrogée sur son processus, met en avant des dispositions aussi douteuses que “on fait super attention”, ou “notre tech lead est un génie du code”, possède un état de l’art probablement inadapté au challenge qu’elle se propose de relever. Là encore, le désalignement appelle le désalignement, et la dégradation s’accélère :

  • l’état de l’art n’étant pas adapté, les résultats s’en ressentent : écarts de budget et retards
  • comme on n’a plus le temps de “bien faire”, on dégrade encore un peu l’état de l’art
  • etc.

comme cette équipe qui, constatant que ses tests de non-régression allaient bientôt prendre plus de temps que la durée d’un sprint, décida de faire moins de tests de non-regression à chaque incrément de fonctionnalités livrées.

La “dette” n’est pas un phénomène émergeant du code, comme une sorte de brouillard technique : elle n’est que le reflet des changements de contexte et des décisions prises sur l’état de l’art.

Stay Tuned !

publié sur Linked In le 11/02/2023