Depuis quelques années, on parle beaucoup dans le milieu du développement de dette technique. Le problème, c’est que c’est un terme trop souvent utilisé comme excuse facile pour justifier un mauvais travail.
A l’origine de la métaphore de Ward Cunningham il y a une analogie avec le monde de la finance.
Lorsque l’on contracte un ou plusieurs crédits bancaires, on s’endette. Si l’on en contracte trop, on est en surendettement et cela devient dangereux pour nos finances. Dans tous les cas, ces crédits doivent être remboursés, généralement avec des intérêts. Tout ce système est clair dès le début, il n’y a pas de surprises.
La dette technique, par analogie, c’est la prise d’un raccourci technique, en étant conscient qu’un jour il faudra la rembourser. Si l’on prend trop de raccourcis, cela devient dangereux pour la base de code. Jusqu’ici on suit facilement l’analogie.
Dans les deux cas, cette dette n’est pas malsaine. De la même façon que l’on peut prendre un crédit pour faire la bonne dépense au bon moment, on peut contracter de la dette technique pour livrer une fonctionnalité avec le bon Time To Market. C’est même une bonne chose, cette décision peut permettre de générer plus rapidement du cash et offrir la possibilité de continuer d’évoluer en payant les intérêts de cette dette technique.
La notion importante ici c’est le choix. De la même façon que l’on ne peut pas s’endetter financièrement sans apposer sa signature en bas d’un contrat de crédit, on ne peut pas non plus s’endetter techniquement de façon accidentelle. Il faut le vouloir.
Sans jamais contracter de crédit financier, on peut se retrouver dans le rouge au niveau bancaire. Ça n’est pas de l’endettement mais une mauvaise gestion de son argent pour diverses raisons, qu’elles soient personnelles (dépenses mal réparties, …) ou extérieures (revenus insuffisants,…).
De la même façon, une base de code peut être pourrie par une mauvaise gestion, qu’elle soit personnelle (manque de compétences, de motivation, travail peu soigné…) ou externe (mauvais process qualité, management nocif, deadlines irréalistes…). C’est même souvent le cas, et les problèmes de communication sont l’une des premières causes de pourriture de base de code sur le long terme, avant l’incompétence technique.
A l’instar de la gestion financière, la gestion du code et l’environnement dans lequel il est produit sont des choses auxquelles il faut prêter de l’attention et du temps. Mais ne pas se donner les moyens de bien faire les choses (ou donner ces moyens aux équipes), ça n’est pas de la dette technique, c’est juste la production de mauvais code.