Il debito tecnico non è 'codice brutto'. È lavoro futuro obbligato, con interessi. Si vede quando una modifica da un giorno diventa una settimana.
Il debito tecnico comincia a costare quando una modifica da un giorno diventa una settimana, quando ogni stima è una finzione e quando i difetti in produzione arrivano da zone che "non si toccano più". Non è codice brutto in sé. È lavoro futuro obbligato, con interessi. Finché gli interessi non si vedono sui rilasci, è solo un'ipotesi da code review.
In breve: Ward Cunningham ha coniato la metafora del debito tecnico: una scorciatoia oggi, interessi dopo. Il costo reale si legge su tre indicatori, cycle time, difetti, affidabilità delle stime, non su una percentuale di "codice a debito". Si paga quando il debito blocca il prodotto. Non quando un commento nel codice è poco elegante.
Cosa trovi in questo articolo
Cosa intendeva Cunningham, e cosa no
Ward Cunningham ha introdotto la metafora del debito tecnico nei primi anni Novanta, nel contesto dello sviluppo di un prodotto finanziario: spedire codice che riflette la comprensione attuale, sapendo che andrà rifattorizzato quando la comprensione cresce. Se non si rifattorizza, gli interessi arrivano sotto forma di rigidità. Martin Fowler ha poi distinto, nel bliki Technical Debt, un debito deliberato e prudente da un debito accidentale o sconsiderato. La metafora regge se la si usa come Cunningham: un prestito con un piano di rientro. Non come alibi per lasciare il disordine.
Due letture sbagliate circolano ancora. La prima: "tutto il codice vecchio è debito". No. Codice stabile, coperto da test, che nessuno ha bisogno di cambiare, può restare com'è. La seconda: una percentuale. "Il settanta per cento del codice è debito" non è una misura, è un lamento. Non esiste un numeratore onesto per quella frazione. Ciò che si può misurare è altro: quanto impiega una storia a uscire, quanti incidenti tornano dalla stessa zona, di quanto sballano le stime su quel modulo.
Il tema sta nel cluster Prodotto perché il debito è una scelta di sequenza: cosa si consegna ora, cosa si lascia come prestito. Non è un voto estetico sul repository.
Quando si vede: cycle time, difetti, stime
Il cycle time è il segnale più onesto. Tempo che passa tra "siamo d'accordo sulla modifica" e "è in produzione". Se su un modulo quel tempo cresce a ogni sprint, mentre il perimetro della modifica resta simile, gli interessi stanno arrivando. Non serve un tool di "debt score". Serve lo storico delle storie su quella zona.
I difetti sono il secondo segnale. Bug che tornano dopo la fix, regressioni su funzioni non toccate, hotfix che ne generano altri. Sono interessi sotto forma di lavoro non pianificato. Il backlog si riempie di "ripristinare X" invece che di "consegnare Y". A quel punto il debito non è più una metafora da retrospettiva. È capacità produttiva mangiata.
Le stime sono il terzo. Quando il team aggiunge sistematicamente un coefficiente "perché quel pezzo è un campo minato", la stima ha smesso di stimare il lavoro nuovo. Sta prezzando la paura. È un dato. Va ascoltato, non corretto a tavolino dal project manager. Se tre persone diverse danno numeri incommensurabili sullo stesso pezzo, il problema non è la tecnica di stima. È l'accoppiamento, l'assenza di test, la conoscenza in testa a una persona sola.
Accanto a questi tre, due segnali deboli ma utili: il tempo per mettere in piedi un ambiente, e il numero di passi manuali per un rilascio. Non sono "debito" in senso stretto. Sono attrito. L'attrito si paga su ogni consegna, quindi si composta.
Cosa non è debito tecnico
Non è debito un'architettura che non piace al nuovo arrivato. Non è debito un linguaggio che non è di moda. Non è debito un CMS scelto tre anni fa, se il team lo sa operare e il prodotto esce. Quello è gusto, o al massimo una discussione sullo stack: vincoli, non mode.
Non è debito, da solo, un plugin in più, un TODO nel codice, una libreria con un major da fare. Possono diventarlo. Lo diventano quando bloccano un rilascio o alzano i difetti. Lo stesso discorso del costo nascosto dei plugin: il listino e l'eleganza non misurano. Misurano runtime, patch, lock-in.
Non è debito neppure "abbiamo scelto di comprare invece di costruire". Quella è una decisione build or buy. Può creare vincoli di uscita. I vincoli di uscita si gestiscono come tali, con un piano, non etichettandoli come colpa morale del codice.
Come si paga, e con chi
Si paga il debito dove gli interessi sono visibili. Un modulo con cycle time in crescita e test assenti vale un intervento dedicato: test di caratterizzazione, spezzare un accoppiamento, documentare il contratto, poi rifattorizzare a pezzi piccoli. Non un "rewrite totale" in un trimestre in cui si deve anche consegnare il catalogo nuovo. Cunningham parlava di rimborso continuo, non di giubileo.
Chi lo fa: il team che già tocca quel codice, con tempo protetto nel piano, oppure un intervento di sviluppo dedicato quando il debito ha superato la capacità interna. In quel secondo caso un fornitore, per esempio i servizi di sviluppo web di Keidea, serve a rimborsare un prestito preciso (un modulo, una batteria di test, una migrazione), non a "riscrivere il sito perché è vecchio". Senza un perimetro, si scambia un debito per un altro: il codice nuovo che nessuno in casa sa operare.
Il rimborso si verifica sugli stessi tre indicatori. Se dopo l'intervento il cycle time su quella zona non scende e le stime restano una finzione, non si è pagato il debito. Si è riscritto. Sono due mestieri diversi.
Ha senso quando. Non serve quando
Ha senso pagare quando una zona del prodotto è sul cammino delle prossime consegne, quando i difetti ripetuti hanno un owner e una frequenza, quando una sola persona sa fare il rilascio. Lì gli interessi sono certi. Si mette una linea nel piano, si misura prima, si misura dopo.
Non serve un progetto "zero debito". Il software che vive accumula prestiti. Alcuni sono deliberati e buoni: si spedisce, si impara, si rifattorizza. Ripulire un angolo che nessuno toccherà nei prossimi due anni è teatro. Costa capacità e non restituisce cycle time. Si lascia stare, si documenta il rischio, si interviene se quella zona torna calda.
Errori da evitare
Usare "debito tecnico" come insulto. Se non si indica cycle time, difetti o stime, si sta parlando di gusto.
Inventare percentuali. Non esiste un "70% di debito". Esiste un modulo che impiega tre volte il previsto.
Riscrivere tutto. Si porta in produzione un sistema nuovo e ignoto, con i suoi interessi, mentre il vecchio ancora serve.
Pagare senza perimetro. "Migliorare la qualità" non è un rimborso. È un calderone. Si nomina il modulo, il segnale, la soglia.
Lasciare il prestito senza scadenza. Una scorciatoia deliberata va in backlog con un owner. Altrimenti è solo disordine con un nome nobile.
In sintesi
Il debito tecnico è un prestito sul futuro del prodotto. Cunningham l'ha detto in questi termini. Si vede quando i rilasci allungano, i difetti tornano, le stime smettono di voler dire qualcosa. Si paga sul modulo che sta sul cammino, con un perimetro e una misura, non con una riscrittura morale. Il resto, gusto, mode, percentuali, è rumore. Il metodo è lo stesso del resto del laboratorio: si misura, si decide, si verifica.
Fonti
Ward Cunningham, metafora del technical debt (1992), sintesi in Agile Alliance, Introduction to the Technical Debt Concept.
Ward Cunningham, Ward Explains Debt Metaphor (c2 wiki).
Martin Fowler, Technical Debt.
Martin Fowler, Technical Debt Quadrant (prudente/sconsiderato, deliberato/accidentale).
Questo contenuto è stato realizzato con il supporto di sistemi di intelligenza artificiale e successivamente verificato secondo le linee editoriali della redazione.
