Un petit changement peut porter une longue histoire
La taille visible d’une demande dit peu de choses sur les décisions accumulées derrière elle.
L’une des premières demandes sur lesquelles j’ai travaillé paraissait rassurante : il fallait modifier une boîte d’information.
Pendant le refinement, un développeur senior a précisé que ce composant existait en plus de vingt variantes. La demande n’avait pas changé ; ma compréhension de sa portée, oui.
J’avais supposé que la taille du ticket refléterait à peu près la complexité du travail. Dans un produit ancien, c’est rarement le cas. Une modification minuscule en surface peut toucher des années de décisions accumulées.
Ces variantes n’étaient pas apparues par accident. Chacune avait probablement répondu à un besoin client, une contrainte réglementaire ou une décision historique difficile à remettre en cause.
Aucune n’était absurde isolément. Ensemble, elles formaient pourtant une complexité invisible pour toute personne découvrant le ticket.
Depuis, lorsqu’un changement paraît petit, je cherche d’abord son historique : combien de versions existent, pourquoi, et quelles hypothèses se sont déposées autour de cette zone du produit ?
Le logiciel n’accumule pas seulement du code. Il accumule des décisions. La taille d’une demande ne révèle presque jamais, à elle seule, la taille du système qu’elle touche.