Un projet, une startup, un site Internet ? C’est toujours la même chose. Vite, vite, vite ! Dit l’initiateur de l’affaire : je veux voir le résultat de mon idée le plus tôt possible. Vite, vite, vite ! Dit le commercial : le time-to-market c’est crucial. Vite, vite, vite ! Disent les financeurs : nous ne voulons pas immobiliser des fonds sans voir quelque chose de concert…
Côté technique on s’exécute. Des solutions à disposition on ne choisit pas la plus robuste, la plus pérenne, la plus efficace, on choisit ce qui est le plus rapide à mettre en œuvre.

Parfois tout se passe bien, le projet est un succès. Les clients demandent de nouvelles fonctionnalités auxquelles personne n’avait pensé, il faut un serveur plus puissant, les questions de sécurité (qu’on avait mises de côté pour aller plus vite) deviennent primordiales. Bref il faut une V2.

Et là, c’est le drame

Parce que la consigne est toujours la même « Vite, vite, vite ». Alors on commence à opérer une dissociation entre ce qui devrait être fait (tout foutre par terre, prendre le temps de réfléchir et repartir sur une base « propre »), et ce qu’on va effectivement faire (ajouter du code en mode « Palais du facteur Cheval »). On fabrique de la dette technique tout en sachant que ce n’est pas ce qu’il faudrait faire et qu’il faudra bien un jour la payer. Bien sûr, se sont souvent des décisions que les développeurs ne prennent pas seuls mais c’est sur eux que pèse le poids du problème. Il faut « faire au mieux », bien tout plâtrer pour que ça passe. Comme dans la Marine Nationale ou quand un navire est trop rouillé on ajoute une couche de peinture. Et version après version, couche après couche, on va vers le naufrage.

Vive la dette

Il ne s’agit pas de considérer la dette technique comme un péché originel (ni la dette financière d’ailleurs, mais c’est une autre histoire). Faire de la dette permet de prendre de l’avance, de tester son idée en acceptant qu’on ne sait pas exactement où l’on va. Mais il faut c’est intégrer la dette technique à son projet et la gérer. Il faut tout d’abord en finir avec l’idée qu’on fait juste un V0 qui est un démonstrateur, et qu’on ne construira pas dessus. Cela n’arrive jamais. Il faut au contraire :

• Accepter l’idée d’écrire du code qui devra être réécrit, et être transparent sur ces points : pourquoi on le fait, pourquoi faudra-t-il réécrire, qu’est-ce que cela coutera.

• Si possible, choisir des technologies pérennes et évolutives et construire une architecture modulaire. Si on ne fait pas ça se sera probablement le tout qui sera à reprendre. Ce n’est pas forcément rédhibitoire, mais il faut le savoir.

• Planifier honnêtement le travail de reprise du code. Parce qu’il n’y a pas qu’un seul niveau dans le « Quick & Dirty ». Il y a du honteux et de l’acceptable. Si ça fait le job, on peut utiliser un bout de code dégueulasse ou une librairie douteuse récupérée sur Github. Mais il sera primordial de s’en débarrasser au plus tôt et en priorité. Et il y a de l’autre côté des choses qu’on pensait devoir remplacer qui se révèlent robustes et qu’on gardera.,

• Ne pas trop attendre pour rembourser. Dans l’idéal dès la livraison de la version 0. Mais il ne faut pas rêver, à chaque nouveau développement, au fur à mesure qu’on paye l’ancienne dette on en créé de la nouvelle. C’est un cycle perpétuel.

À ses conditions la dette techniques ne sera plus cette menace diffuse qui pourrit nos développements et provoque des suées froides à chaque demande.