Pourquoi la dette technique est-elle si présente dans nos projets ? Si c’est aussi courant, c’est qu’il y a des raisons systémiques. Pour éviter de faire le Don Quijote et se battre contre des moulins inébranlables, nous devons comprendre les forces qui entraînent l’accumulation de dette technique et trouver des astuces pour changer les choses, souvent en nous-mêmes, pour améliorer la situation. Dans cette vidéo, je présente quelques-unes des ces forces.

Face à un code désorganisé, on choisit souvent de ne rien faire pour éviter de “tout casser”. Dans ce contexte que l’on peut qualifier d’entropie (désorganisation), l’inaction est considérée comme moins risquée puisque l’on n’a pas suffisamment d’expérience de tests pour améliorer la situation. C’est l’entropie couplée à l’inaction qui amènent fatalement à une accumulation de la dette technique.

Pourtant une autre voie existe. En choisissant dès le départ de mettre en place des tests, de s’entraîner à les écrire plus rapidement, on se donne les moyens d’exploiter au maximum le refactoring indispensable pour maintenir le projet en bon état.