Debito tecnico: cos'è, come misurarlo e quando intervenire

Il debito tecnico è il costo futuro delle scorciatoie prese oggi nello sviluppo di un software: codice scritto in fretta, test mancanti, dipendenze non aggiornate, architetture pensate per un'azienda più piccola di quella attuale. Come un debito finanziario, fa guadagnare tempo subito e genera interessi dopo: ogni modifica costa più lavoro e più rischio, finché qualcuno non decide di ripagarlo. Se vi serve sapere quanto debito porta il vostro sistema e dove, è il lavoro di una due diligence tecnica del software.

Questa guida spiega da dove nasce il debito tecnico, quali segnali permettono a un CTO o a un imprenditore di misurarlo senza leggere il codice, quanto costa ignorarlo secondo gli studi pubblici disponibili e quando conviene chiamare qualcuno dall'esterno.

In sintesi

• Il termine nasce nel 1992 da Ward Cunningham: il codice "non ancora giusto" è un debito, e ogni minuto speso a lavorarci sopra è un interesse pagato.
• Non tutto il debito tecnico è un errore: quello contratto consapevolmente, per arrivare prima sul mercato, è una scelta. Il problema è il debito che nessuno registra e nessuno ripaga.
• Si misura con segnali di delivery (tempi e stabilità dei rilasci), del codice (test, dipendenze, aree fragili) e dell'organizzazione (lavoro non pianificato, dipendenza da poche persone).
• Nel sondaggio McKinsey del 2020, i CIO stimavano che il 10-20% del budget tecnologico per i nuovi prodotti finisse a risolvere problemi di debito tecnico.
• Refactoring incrementale e riscrittura sono due modi diversi di ripagarlo: la scelta si fa su evidenze, non sull'età del codice.

Cos'è il debito tecnico?

Il debito tecnico è la differenza tra come un software è fatto oggi e come dovrebbe essere fatto per poter cambiare in fretta e in sicurezza. Ogni volta che si sceglie la soluzione più rapida invece di quella più solida, si prende in prestito tempo dal futuro. Il prestito si paga con gli interessi: bug più frequenti, rilasci più lenti, sviluppatori che passano le giornate a capire il codice invece di migliorarlo.

La metafora viene da Ward Cunningham, che nel 1992, presentando il sistema WyCash alla conferenza OOPSLA, scrisse che consegnare codice alla prima stesura è come indebitarsi: un po' di debito accelera lo sviluppo, purché venga ripagato in fretta con una riscrittura; il pericolo arriva quando il debito non viene ripagato, perché ogni minuto speso su codice "non proprio giusto" conta come interesse.

La metafora funziona perché parla la lingua del business. Un CFO non ha bisogno di sapere cos'è un modulo accoppiato per capire che un debito non registrato, con un tasso di interesse che cresce, è un rischio da mettere a bilancio.

Quali tipi di debito tecnico esistono?

Il modo più utile per classificarlo resta il quadrante proposto da Martin Fowler nel 2009, che incrocia due domande: il debito è stato contratto consapevolmente o no? E con prudenza o con leggerezza?

Il quadrante chiarisce un punto spesso frainteso: il debito prudente e consapevole è normale in qualsiasi prodotto che deve arrivare sul mercato. Il debito involontario e prudente è inevitabile, perché un team capisce davvero il problema solo dopo averlo risolto una volta. Il debito da evitare è quello contratto con leggerezza, e soprattutto quello che nessuno ha mai registrato.

Nella pratica il debito si accumula in quattro zone:

• Codice: duplicazioni, funzioni enormi, logica di business sparsa ovunque, assenza di test automatici.
• Architettura: componenti così accoppiati che una modifica in un punto rompe qualcosa altrove.
• Infrastruttura e dipendenze: librerie, framework, database e sistemi operativi arrivati a fine supporto.
• Conoscenza: documentazione assente e parti del sistema che solo una persona sa modificare.

Da dove nasce il debito tecnico?

Il debito tecnico nasce raramente da sviluppatori incompetenti. Nasce da decisioni ragionevoli prese sotto pressione e mai riviste:

• Scadenze commerciali che spingono a rilasciare la prima versione funzionante, senza tempo per sistemarla dopo.
• Requisiti che cambiano più in fretta dell'architettura: il software resta disegnato per un business che non esiste più.
• Turnover del team e dei fornitori, con conoscenza che se ne va insieme alle persone.
• Assenza di test automatici, che rende ogni modifica una scommessa e quindi scoraggia chi vorrebbe migliorare il codice.
• Aggiornamenti rimandati di librerie e piattaforme, finché il salto di versione diventa un progetto a sé.
• Codice generato in fretta, anche con assistenti di intelligenza artificiale, accettato senza una revisione senior su test, dipendenze e sicurezza.

Quando queste cause si sommano per anni, il debito trasforma il software in un sistema legacy: ancora critico per il business, ma sempre più difficile da cambiare.

Come si misura il debito tecnico?

Non esiste un numero unico che misuri il debito tecnico, e diffidate di chi ve lo promette. Esistono però segnali concreti che un CTO, o un imprenditore senza competenze tecniche, può verificare in poche settimane. Presi insieme, dicono quanto debito c'è e dove.

Segnali di delivery. Le metriche di delivery del programma di ricerca DORA sono il punto di partenza più solido, perché misurano gli effetti del debito invece del debito in sé:

• tempo che passa tra una modifica al codice e il suo arrivo in produzione;
• frequenza dei rilasci;
• percentuale di rilasci che richiedono un intervento immediato, come un rollback o una correzione urgente;
• tempo necessario per ripristinare il servizio dopo un rilascio fallito;
• quota di rilasci non pianificati, fatti solo per rimediare a un incidente in produzione.

Se i rilasci rallentano e falliscono più spesso mentre il team resta lo stesso, il debito sta crescendo.

Segnali del codice.

• Copertura dei test automatici sui flussi che portano ricavi o dati sensibili, non la percentuale media su tutto il codice.
• Dipendenze, framework e versioni di database fuori supporto o con vulnerabilità note.
• "Punti caldi": i file che cambiano più spesso e sono anche i più complessi. Lì il debito costa di più, perché gli interessi si pagano a ogni modifica.
• Tempo di build e di avvio dell'ambiente di sviluppo.

Strumenti di analisi statica come SonarQube stimano il debito in giorni di lavoro, con metodi derivati da SQALE. Sono utili per seguire una tendenza nel tempo, meno per decidere: non sanno quali parti del codice contano per il business.

Segnali organizzativi.

• Quota del lavoro di ogni sprint spesa in bug e attività non pianificate.
• Parti del sistema che solo una persona sa modificare.
• Settimane necessarie perché un nuovo sviluppatore rilasci la sua prima modifica in produzione.
• Stime che sbagliano sempre nella stessa direzione sulle stesse aree del sistema.

Quanto costa ignorare il debito tecnico?

Il costo del debito tecnico di un sistema specifico si stima solo analizzandolo. Gli studi pubblici però danno l'ordine di grandezza, e conviene citarli con il loro perimetro:

Queste cifre non sono il costo del vostro software. Dicono però una cosa coerente: il debito tecnico non resta fermo. Gli interessi si pagano in tempo degli sviluppatori, in budget sottratto a nuove funzioni e in rischio operativo, e crescono se nessuno li gestisce. Il caso britannico mostra dove si arriva: quando quasi tutto il budget va a tenere in vita i sistemi esistenti, non resta niente per cambiarli.

C'è poi un costo che le tabelle non catturano: la sicurezza. Componenti fuori supporto non ricevono più patch, e un sistema che nessuno osa toccare è anche un sistema che nessuno aggiorna.

Debito tecnico in Agile e Scrum: come gestirlo nel backlog

Nei team Agile il debito tecnico cresce quando resta invisibile: le storie utente hanno un product owner che le difende, le voci di debito no. Tre pratiche lo riportano sotto controllo:

• Registrarlo nel backlog come qualsiasi altro lavoro, con una descrizione dell'impatto sul business, una stima e un responsabile.
• Riservare una quota fissa di ogni sprint al rimborso, invece di sperare in uno "sprint tecnico" che non arriva mai.
• Includerlo nella Definition of Done: una funzione non è finita se lascia test mancanti o dipendenze obsolete dietro di sé.

La priorità va data al debito nelle aree che cambiano più spesso e che causano più incidenti, non al codice che sembra più brutto. Un modulo vecchio ma stabile e mai toccato può aspettare.

Refactoring o riscrittura: come si ripaga il debito tecnico?

Ci sono due modi per ripagare il debito tecnico: il refactoring, che migliora la struttura del codice esistente senza cambiarne il comportamento, e la riscrittura, che sostituisce un componente o l'intero sistema.

• Refactoring incrementale: è la strada giusta nella maggior parte dei casi. Si aggiungono test sui flussi critici, poi si migliora una parte alla volta, iniziando dai punti caldi. Il business non si ferma e ogni passo è reversibile.
• Sostituzione progressiva (strangler fig): si costruiscono le nuove funzioni attorno al vecchio sistema, dietro interfacce stabili, e si spostano le responsabilità una alla volta finché il vecchio componente si può spegnere.
• Riscrittura completa: conviene quando le fondamenta non reggono più il carico, la tecnologia non è più supportata o il modello di business è cambiato. È anche l'opzione con più rischio, perché per mesi si mantengono due sistemi.

Le domande che decidono tra queste opzioni sono nel nostro framework su riscrittura o refactoring, scritto per i CTO di aziende di medie dimensioni.

Quando chiamare un audit sul debito tecnico?

Un audit esterno serve quando il debito ha smesso di essere un tema del team tecnico ed è diventato un tema del business. I segnali tipici:

• ogni rilascio porta incidenti, e il team ha paura di toccare alcune parti del sistema;
• le stime su nuove funzioni crescono senza che il perimetro cambi;
• una parte critica del sistema dipende da una sola persona, interna o di un fornitore;
• dovete decidere se riscrivere, e le opinioni interne sono divise;
• state per acquisire un'azienda o un prodotto software, o un investitore vi chiede lo stato reale della tecnologia;
• normative come NIS2 o requisiti dei clienti impongono di dimostrare come gestite sicurezza e aggiornamenti.

In questi casi una due diligence tecnica del software di produzione dice cosa è a rischio, quanto costa sistemarlo e in che ordine, con un report scritto in due-quattro settimane. È il modo di trasformare il debito tecnico da sensazione a voce di bilancio: un elenco di criticità ordinate per impatto sul business, con una stima di effort per ciascuna. Nel caso Neotecnica, per esempio, l'audit del codice e della sicurezza si è chiuso con oltre 13.000 issue analizzate e più di 19 vulnerabilità risolte.

Se invece il debito ha già superato il livello di guardia, e il sistema si rompe in produzione mentre il business deve continuare a usarlo, il passo successivo è la stabilizzazione del software legacy: riparazione sistematica di ciò che si rompe, test sui flussi critici e rilasci di nuovo prevedibili, senza fermare l'operatività.

Volete capire quanto debito tecnico porta il vostro software e da dove conviene iniziare a ripagarlo? Scriveteci: ne parlerete con il nostro team di ingegneria, e vi diremo se serve un audit, un intervento di stabilizzazione o se il vostro team può gestirlo da solo.

Contatta il nostro team di ingegneria →

Fonti

• Ward Cunningham, "The WyCash Portfolio Management System", experience report OOPSLA '92 (1992): c2.com
• Martin Fowler, "Technical Debt Quadrant", 14 ottobre 2009: martinfowler.com
• McKinsey & Company, "Tech debt: Reclaiming tech equity", 6 ottobre 2020 (consultato il 7 ottobre 2026): mckinsey.com
• Stripe, "The Developer Coefficient", settembre 2018 (consultato il 7 ottobre 2026): stripe.com
• CISQ, "The Cost of Poor Software Quality in the US: A 2022 Report", con il comunicato Synopsys del 6 dicembre 2022 (consultato il 7 ottobre 2026): it-cisq.org
• UK Department for Science, Innovation and Technology, "State of digital government review", 21 gennaio 2025: gov.uk
• DORA, "DORA's software delivery performance metrics", aggiornata il 5 gennaio 2026 (consultata il 7 ottobre 2026): dora.dev