Debito tecnico

Il debito tecnico è il costo accumulato di scelte di implementazione che, pur essendo convenienti al momento, rendono i futuri cambiamenti più lenti o rischiosi. La metafora è di Ward Cunningham: si tratta di un prestito garantito dalla futura capacità di rilasciare un prodotto prima, con interessi da pagare a ogni successiva modifica fino al rimborso del debito. Come il debito finanziario, non è intrinsecamente negativo, e la distinzione fondamentale sta tra un debito contratto deliberatamente per una ragione specifica e un debito accumulato per negligenza.

Il valore della metafora sta nel rendere il compromesso discutibile anche a chi non si occupa di programmazione. Inquadrare una richiesta di refactoring come rimborso di un debito comunica qualcosa che una richiesta di riscrivere un modulo non riesce a fare, ovvero che il costo è già stato sostenuto, con tempi di consegna più lunghi e tassi di difettosità più elevati, e che la questione è se continuare a pagarlo. La formulazione originale di Cunningham sottolineava inoltre che il debito deriva da un divario crescente tra la struttura del codice e la comprensione attuale del problema da parte del team, un concetto più ampio del semplice scrivere codice approssimativo sotto pressione.

Sotto questo termine rientrano diverse problematiche distinte, che richiedono risposte differenti. Il debito tecnico deliberato, assunto consapevolmente per rispettare una scadenza reale con un piano per gestirlo, è una legittima decisione ingegneristica. Il debito tecnico accidentale, derivante da un miglioramento della comprensione da parte del team dopo la definizione del progetto, è inevitabile e rappresenta il normale costo dell'apprendimento. Il debito tecnico dovuto a negligenza, causato da test assenti, comportamenti non documentati e dipendenze non gestite, si accumula silenziosamente ed è la categoria più costosa perché rende ogni modifica più rischiosa. Le dipendenze obsolete, in particolare, comportano rischi per la sicurezza, oltre al semplice inconveniente.

I sintomi sono visibili nelle metriche di consegna prima ancora di essere visibili nel codice. Stime in aumento per lavori simili, una quota crescente di capacità impiegata per correggere i difetti, la riluttanza a intervenire su determinate aree e modifiche in un punto che causano problemi a elementi non correlati, sono tutti segnali che il pagamento degli interessi è diventato consistente. I team spesso segnalano questi sintomi come problemi di capacità e richiedono ulteriore personale, il che di solito peggiora la situazione nel breve termine.

La sua gestione richiede che il lavoro sia visibile nello stesso processo di pianificazione di tutto il resto. Il debito accumulato in un elenco separato, che viene affrontato solo quando c'è capacità disponibile, non viene mai affrontato, perché la capacità disponibile non c'è mai. Assegnare una percentuale fissa di ogni ciclo a tale scopo, oppure collegare gli interventi correttivi al lavoro sulle caratteristiche nelle aree interessate dalle modifiche, sono i due approcci che resistono alle pressioni commerciali. L'alternativa, ovvero le riscritture periodiche di grandi dimensioni, è solitamente sintomo di un ritardo eccessivo nel lavoro e comporta rischi ben maggiori rispetto a un miglioramento incrementale.

Comunicare la necessità di interventi correttivi funziona meglio in termini di implementazione che in termini di ingegneria. Affermare che una determinata area ora richiede tre volte più tempo per essere modificata rispetto ad aree comparabili, supportando la tesi con dati provenienti da lavori recenti, collega il problema a qualcosa che interessa già agli stakeholder non tecnici, mentre descrivere le problematiche architetturali non ha lo stesso effetto. Quando il debito tecnico comporta un rischio piuttosto che un costo, come nel caso di dipendenze non gestite o di una copertura di test insufficiente sui percorsi critici, inquadrarlo come un'esposizione con una probabilità e un impatto è più efficace che inquadrarlo come un problema di qualità. In entrambi i casi, quantificare il costo continuo è ciò che trasforma una preferenza ingegneristica in un business case in grado di competere con lo sviluppo di nuove funzionalità per le risorse disponibili.

Non tutti i debiti devono essere ripagati. Il codice che funziona, cambia raramente e non causa problemi può rimanere così com'è, indipendentemente dal suo aspetto, e lo sforzo impiegato per migliorarlo non produce alcun ritorno. L'approccio economicamente valido concentra la correzione dove i cambiamenti sono frequenti e dove, di conseguenza, gli interessi vengono effettivamente pagati. Rendere visibile questo compromesso e riservare esplicitamente la capacità necessaria nella pianificazione è una parte normale del modo in cui un sviluppo del prodotto Il coinvolgimento è strutturato e appartiene alla discussione sulla roadmap all'interno di un studio di prodotto piuttosto che essere trattata come una questione ingegneristica esterna alla discussione sul prodotto.