Posso darti un esempio dalla mia esperienza.

Circa 10 o 12 anni fa ho ereditato un'applicazione da un team di sviluppatori che ha lasciato l'azienda (troppo tempo per entrare qui ...). Il sistema era un grande sistema di generazione di report middleware sviluppato in casa. Funzionava ogni settimana e generava circa 2 dozzine di report Excel per dirigenti di un'azienda Fortune 500. Quando l'ho ereditato, ci sono volute circa 5-6 ore per funzionare e durante una data settimana avrebbe fallito almeno 2 notti.

Non ero un campeggiatore felice per questo pasticcio.

Inizialmente il mio piano era solo per fermare il sanguinamento e correggere la causa principale dei fallimenti. Dopo essere diventato più a mio agio con la base di codice, ho iniziato a cercare luoghi in cui potevo refactoring e aggiungere stabilità e prestazioni. Nel corso di 2 anni circa, ho apportato molte, molte modifiche al sistema. Abbiamo ritirato questo sistema un paio di anni fa ea quel punto l'intero processo impiegava 45 minuti per funzionare e non aveva generato alcun problema in anni.

Un sacco di lavoro è andato a pagare il debito tecnico, ma è andata bene, ne è valsa la pena. È stato bello non ricevere alcuna telefonata nel cuore della notte che il sistema abbia fallito. E 'stato bello entrare in ufficio nel monring e non vedere nient'altro che buone notizie nei log.

(A parte ... Dopo un paio d'anni mi sono imbattuto in uno dei principali sviluppatori di questo sistema, mi ha chiesto come funzionava e gli ho detto quanto fosse pessimo il sistema. In realtà si è scusato e mi ha detto che sapeva sarebbe una manciata da sostenere dopo che se ne andò e desiderò che avesse fatto un lavoro migliore su di esso).

È stata la mia esperienza che i vantaggi della pulizia del codice sono più evidenti quando devo mantenere il codice in cui la pulizia non è stata eseguita. Nei casi in cui è stata effettuata la pulizia, i miei cambiamenti consistono nella lettura del codice, nella individuazione di uno o due punti che devono essere modificati e in corso da lì. Se la pulizia non è stata eseguita, aggiungi un primo passaggio per leggere il codice un paio di volte e cerca di capire che cosa l'autore (a volte io) stava pensando quando lo ha scritto.

eliminando i rendimenti del debito tecnico meno supporto tecnico e una base migliore per i miglioramenti

sempre

Un'esperienza che ho avuto è stata quando gestivo un team di Site Performance presso il mio precedente datore di lavoro. Ogni notte, per un periodo da un'ora a due ore, il sito Web che il mio team stava monitorando sarebbe sceso al di sotto delle soglie di prestazione accettabili a causa di un rapido scrap di bot dal sito. Le misure adottate dal team per risolvere questo problema consistevano nell'accedere a un sistema di amministrazione manuale e nel bloccare gli indirizzi IP che causavano i problemi. Inutile dire che questo costa ad un membro della squadra ore di sonno quasi ogni notte. Ho notato che cosa stava succedendo e ho preso il BlackBerry da solo per diversi giorni per vedere quanto fosse pessimo e dare al mio team un po 'di riposo.

Dopo pochi giorni, sono semplicemente andato dal proprietario del business del team e gli ho fatto sapere che se non avessimo implementato un sistema di blocco automatico in modo tale che i robot avrebbero avuto un tempo molto più difficile per le prestazioni del sito, noi probabilmente perderebbe alcuni se non tutti i membri del team a causa della fatica e del burnout. Hanno concordato e abbiamo implementato un sistema che ci ha permesso di dormire la notte. L'imprenditore ha capito che il costo di alcuni giorni o una settimana di sviluppo era minimo rispetto al costo di assunzione / formazione di nuovi ingegneri.

Riguardo agli ultimi due punti: capisco da dove proviene, come spiegato nel suo post originale :

Or, is it possible to reassign some developers to get these technical matters done, while the rest of the team continues on the user-oriented stuff? This may affect team velocity, but so what?

     

"Quindi cosa" equivale a: il proprietario del prodotto   e altre persone di affari diventano   infelice. E quando la mamma è infelice,   tutti sono infelici.

Tuttavia, il confine tra ciò che deve essere fatto e ciò che può essere fatto è piuttosto vago. La faccia da utente è molto ampia e include prestazioni e occorrenza di errori. Ma in alcuni casi, il problema di fondo delle scarse prestazioni e l'alta frequenza di errori risiede più in profondità nel codice. Per dirla con le sue parole: una storia potrebbe non attraversare un'area crudista, ma quella zona crufty può nascondere alcune cose sgradevoli che attaccano la storia sul percorso ripulito accanto ad essa.

Le cose che non influenzano le prestazioni complessive sono meno interessanti da ripulire, ma si dovrebbe valutare molto attentamente l'influenza di quei punti. Più spesso hanno un'influenza indiretta che può essere piuttosto sostanziale.

Il maggiore beneficio che un'organizzazione riceverà in seguito al pagamento del debito tecnico sta evitando l'interesse composto. C'è un esempio nel post di blog qui sotto che mostra come l'importo principale dovuto per un debito tecnico è passato da $ 160.000 a $ 430.000 in soli cinque anni. Ci vorrebbe un programmatore a tempo pieno dedicato esclusivamente al servizio di quell'ammontare del debito. Ciò contribuirà a metterlo in prospettiva per i decisori!

Da blog.acrowire.com .