Dette technique : quand la contracter et quand la rembourser

Tout raccourci n'est pas une dette

Un code simple qui suffit au besoin actuel n'est pas une dette, même s'il n'est pas générique. La dette, c'est le choix délibéré d'une solution qui coûtera plus tard : une duplication dont on sait qu'elle se divisera, un test reporté, une structure de données qui ne survivra pas à la croissance.

Un mauvais code écrit par ignorance n'est pas une dette mais un futur bug. La distinction compte parce que le traitement est différent.

Quand vaut-il mieux la contracter

Quand on ne sait pas encore si la fonctionnalité restera. Inutile de bâtir une infrastructure parfaite pour quelque chose qui pourrait être supprimé dans un mois.

Quand il y a une vraie fenêtre de temps : un lancement, un client, une réglementation. Mais alors on note ce qui a été reporté, où dans le code, et le signal qui obligera à revenir.

Comment rembourser sans tout arrêter

« On s'arrête un mois et on remet de l'ordre » n'est presque jamais approuvé. Ce qui fonctionne : rembourser au fil de l'eau — chaque fois qu'on touche une zone problématique, l'améliorer un peu. Et allouer une part fixe de chaque cycle de travail à la maintenance, comme on en alloue aux fonctionnalités.

Préférez rembourser là où on touche souvent. Le code laid que personne n'a ouvert depuis deux ans n'est pas votre problème.