Quels gains avez-vous vus en prenant soin de la dette technique?

Question

Cette Article sur la dette technique A de bons points, notamment:

Travailler sur les «questions techniques» fonctionne mieux lorsqu'elle est motivée par les histoires. La base de code a probablement besoin de travail partout, mais le gain ne sera reçu que lorsque le code sera travaillé pour des raisons orientées par les utilisateurs. Si aucune histoire ne va passer dans une zone crufty, y travailler est largement gaspillée.

Par conséquent, je préfère l'approche de prendre des histoires comme d'habitude (mais probablement moins d'entre elles), et de suivre la "règle de Boy Scout" de quitter le terrain de camping que vous ne l'avez trouvé. En d'autres termes, partout où les histoires nous mènent, écrivons plus de tests, refactorons de manière plus agressive.

Cette approche présente au moins ces avantages:

• maintient le flux "le mieux judicieux" d'histoires;
• fournit l'aide de tous les talents de l'équipe;
• Fournit l'équipe entière pour apprendre à garder le code propre;
• concentre l'amélioration exactement là où elle est nécessaire;
• Ne gaspille pas une amélioration qui peut "être nécessaire";

J'ai vu que la qualité du code a un très grand effet sur la productivité à long terme, donc je crois que la dette technique devrait être prise en charge. Je pense que le post ci-dessus a du sens, mais je ne suis pas sûr des deux derniers points. Je suis intéressé à découvrir de véritables expériences de avantages du nettoyage de la dette technique, même si elle n'était pas liée aux histoires d'utilisateurs.

Quels avantages positifs avez-vous vu en nettoyant votre base de code et en vous débarrassant de la dette technique? Quelles méthodes avez-vous utilisées pour faire le travail?