Dette technique ou code pourri ?

Récemment, j'ai regardé à nouveau l'excellente conférence d'Arnaud Lemaire sur la dette technique. D'ailleurs je vous la recommande chaudement si vous ne l'avez pas encore vue.
Et je me suis dit qu'il fallait aborder à nouveau le sujet de la dette technique.

Le contexte

Voici Gilles :

Gilles est développeur front-end.
Il travaille dans une équipe qui applique sa méthode... à lui... celle qu'on appelle la méthode à Gilles.

Ce matin, un collègue lui dit :

Le sprint va finir dans 2 jours, on a terminé la feature d'ajout mais il faut maitenant développer la feature d'édition.
Et si on faisait un copier/coller du code, en modifiant juste le strict nécessaire, sans effectuer de refacto/nettoyage ?

Les conséquences

Gilles se dit que c'est une mauvaise idée, mais il n'a pas vraiment le temps de faire autrement.
Ni une ni deux, il copie le code et modifie le strict nécessaire, puis il livre la feature d'édition.

Le sprint suivant, l'équipe est en retard et ils n'ont pas le temps de revenir mettre au propre ce fameux bout de code. Et le sprint qui suit ça sera pareil, et ça continuera, ça restera comme ça jusqu'à la nuit des temps.
Ce bout de code ne sera jamais refacto.

Concrètement, que s'est-il passé ?

En fait, l'équipe a ajouté de la complexité accidentelle (ceci fera l'objet d'un autre post).
Si cet évènement se produit trop souvent et que la complexité s'accumule, le logiciel peut devenir ingérable et ça peut devenir le fameux code legacy qui nous fait perdre 1/10ème par oeil à chaque lecture de ligne.

Si c'est pas de la dette technique, qu'est ce que c'est ?

En fait, on peut appeler ça du code pourri, de la pourriture logicielle (rotten software).
Ah oui en effet c'est beaucoup moins joli que dette technique, mais c'est plus réaliste.

La soit disante "dette" a tellement grossi, les intérêts sont tellement énormes. Et rien n'a jamais été remboursé, du coup le prix à payer est colossal...

Tu nous gonfles !! C'est quoi la dette technique alors ?

La dette technique, c'est quand on fait un choix technique qui nous permet d'aller plus vite maintenant, mais qui nous ralentira plus tard.
C'est un choix conscient, qui est fait pour une raison précise, et qui est assumé.

Et surtout c'est une décision business, qui doit se négocier.

Lorsqu'on a besoin rapidement de livrer une feature pour signer un client, là ça peut-être un choix conscient.
En revanche, la dette technique n'est pas un joker pour coder de la m***e et livrer n'importe quoi.

Une fois qu'un accord est trouvé entre le business et les développeurs. Le business doit donner carte blanche aux développeurs pour rembourser la dette technique quand ces derniers le décident.