Comment décidez-vous du temps à consacrer à la dette technique par rapport aux nouvelles fonctionnalités ?

Traitez la dette comme un coût pour l'entreprise plutôt que comme une question morale. Quantifiez-la : de combien ralentit-elle la livraison, combien d'incidents cause-t-elle, que se passe-t-il si elle lâche. Puis financez-la dans la même conversation que les fonctionnalités, soit par une allocation permanente (souvent quinze à vingt pour cent), soit rattachée au travail de roadmap qui touche cette zone. Remboursez la dette qui porte vraiment des intérêts, pas le code que vous n'aimez pas.

Je refuse d'en faire un argument moral séparé, parce que l'ingénierie perd toujours celui-là. J'en fais une conversation de coût. On tient un registre de dette avec une estimation de ce que chaque élément nous coûte : ce service ajoute deux jours à chaque fonctionnalité qui le touche, celui-là a causé quatre des dix derniers incidents, cette dépendance sort du support dans neuf mois et bloque un renouvellement de conformité. Ensuite je priorise par taux d'intérêt plutôt que par laideur du code, parce que plein de code horrible est stable, jamais touché, et peut le rester pour toujours. Sur le financement, mon réglage par défaut c'est vingt pour cent permanents plus le nettoyage rattaché au travail de roadmap, donc si on est déjà dans cette zone on corrige au passage. L'argument qui porte auprès du produit, c'est toujours celui de la livraison. Dans ma dernière équipe, je pouvais montrer que deux tiers de notre temps d'incident venaient d'un seul chemin legacy, et une fois posé comme on perd une semaine par mois là-dessus, la correction de six semaines s'est vendue toute seule au lieu d'être une bagarre.