Quali payoff hai visto dal prendermi cura del debito tecnico?

Question

Questo Articolo sul debito tecnico ha alcuni buoni punti, tra cui:

Lavorare sulle "questioni tecniche" funziona meglio quando è guidato da storie. La base di codice ha probabilmente bisogno di lavoro ovunque, ma il payoff verrà ricevuto solo in cui il codice verrà lavorato per motivi rivolti all'utente. Se nessuna storie passerà attraverso un'area cromatica, lavorarci sopra è in gran parte sprecato.

Pertanto, preferisco l'approccio di adottare storie come al solito (ma probabilmente meno di esse) e seguire la "Regola Boy Scout" di lasciare il campeggio meglio di quanto tu lo abbia trovato. In altre parole, ovunque le storie ci guidino, scriviamo più test, refactor in modo più aggressivo.

Questo approccio presenta almeno questi vantaggi:

• mantiene il flusso di storie "meglio sensibile";
• fornisce aiuto da tutti i talenti del team;
• Fornisce l'intera squadra per imparare a mantenere pulito il codice;
• focalizza il miglioramento esattamente dove è necessario;
• non è necessario un miglioramento che "possa" essere necessario;

Ho visto che la qualità del codice ha un effetto molto grande sulla produttività a lungo termine, quindi credo che il debito tecnico dovrebbe essere curato. Penso che il post sopra abbia senso, ma non sono così sicuro degli ultimi due punti. Sono interessato a scoprire esperienze reali di benefici dalla pulizia del debito tecnico, anche se non era correlato alle storie degli utenti.

Quali benefici positivi hai visto dalla pulizia della tua base di codice e dalla liberazione del debito tecnico? Quali metodi hai usato per svolgere il lavoro?