Il debito tecnico è un asset tossico: come i leader tecnologici devono rinegoziare il contratto con il business

Avete mai provato a spiegare al CdA perché è necessario rallentare lo sviluppo per “sistemare il codice”? In quel momento, gli occhi del CEO si gonfiano esattamente come la settimana di Ferragosto, quando nessuno fattura e tutti sono in ferie. Di fronte a lui il CFO sospira, calcolando mentalmente il ROI di un lavoro invisibile che farà perdere tempo nell’implementazione di quelle feature che i clienti stanno disperatamente cercando.

Non sapendo come descrivere il problema, cercando le parole giuste, provate a pronunciare la formula magica:

debito tecnico

Se siete convinti che questa metafora finanziaria creerà finalmente un ponte con il business, vi svelo un segreto: non ha funzionato, non funzionerà mai ed è in buona parte colpa nostra.

Il problema non è il disinteresse del business, ma l’uso di un vocabolario inadeguato per descrivere un rischio reale. Per un ingegnere del software, il debito tecnico è tangibile: librerie obsolete, accoppiamento rigido, assenza di test automatizzati e codice privo di documentazione: come facciamo a spiegare che qualcosa non è realizzabile perché l’azienda che ci fornisce quel componente fondamentale per il nostro business ha chiuso? O il programmatore di Bangalore che produceva il prodotto open source che tanto ci piaceva è stato assunto da una BigTech e ha accumulato un backlog di modifiche lungo come un treno per Rimini in un weekend d’agosto?

Per un manager focalizzato sul budget suona come la richiesta di ripulire una stanza: un’attività utile, ma rimandabile a tempo indefinito finché non si presentano emergenze.

È il momento di cambiare la cornice, non il messaggio. I leader tecnologici che ottengono budget, consenso e rispetto sono quelli che traducono la realtà ingegneristica nel linguaggio degli asset aziendali, del rischio operativo e del TCO. Non si tratta di semplificare, ma di parlare la stessa lingua del business.

Il codice di bassa qualità non è un debito gestibile: è un asset tossico che genera esternalità negative sull'intero bilancio aziendale.

Dal “debito” all’asset tossico: il cambio di vocabolario che vale milioni

Quando Ward Cunningham coniò il termine “debito tecnico” nel 1992 (di cui si può leggere la spiegazione originale sulla C2 Wiki), aveva un obiettivo preciso: spiegare ai manager che rilasciare codice imperfetto per accelerare i tempi di consegna equivale a contrarre un prestito finanziario. La metafora era brillante per l’epoca, ma oggi, di fronte a un CFO che gestisce investimenti reali, rischia di ritorcersi contro il team tecnologico.

Il motivo è sottile: nel mondo finanziario il debito è spesso uno strumento strategico e utile. Senza debito le aziende non possono finanziare l’espansione, acquisire concorrenti ed entrare in nuovi mercati. Un debito gestibile permette di espandere l’azienda molto più velocemente che senza di esso.

Quando un CTO dichiara di voler risanare il debito tecnico, il business sente implicitamente: “vogliamo estinguere un prestito che ci ha permesso di accelerare e di cui stiamo pagando gli interessi”. La reazione ovvia del board sarà immediata: “perché farlo proprio adesso quando ci sono richieste di business più importanti?”

Il codice di bassa qualità non è un debito gestibile

In termini finanziari, si tratta di un vero e proprio asset tossico: una voce di bilancio che si deprezza e genera esternalità negative sull’intero ecosistema aziendale. Parliamo di un rischio non coperto che cresce silenziosamente nel patrimonio tecnologico dell’azienda. L’effetto nel tempo è quello di rallentare ogni rilascio di funzionalità, aumentare l’onboarding di ogni nuovo sviluppatore, rendere ogni nuova modifica un dedalo di compromessi sempre maggiore.

Quando un istituto finanziario scopre di avere asset tossici in portafoglio, agisce tempestivamente perché sa che il mercato chiederà conto del rischio. Il software non fa eccezione. Il mercato, sotto forma di concorrenti più rapidi, clienti esigenti e sviluppatori che lasciano l’azienda, presenterà il conto prima o poi. E sarà un conto molto più salato del previsto.

Ricordo ancora quando un cliente mi chiese di apportare alcune modifiche a un software perché lo sviluppatore precedente non era più in azienda. Il problema non era implementare le modifiche in sé, ma il fatto che il codice avesse subito anni di stratificazioni tecnologiche disordinate, senza un criterio comune.

Era un labirinto tempestato di condizioni “ad hoc” per clienti non più attivi, privo di test automatizzati e con flussi logici in collisione. In contesti simili, ogni intervento è una scommessa: il costo e il rischio di regressioni sono altissimi. Anche una modifica banale sulla carta può trasformarsi in un impegno gigantesco.

Persino i moderni assistenti AI faticano in scenari del genere. Senza una coerenza strutturale di fondo, nessun copilota digitale può fare miracoli o trovare logica dove regna il caos.

C’è poi un paradosso moderno: gli stessi assistenti di codifica AI, se usati senza criteri rigidi di governance, stanno agendo da formidabili moltiplicatori di debito tecnico. Generare righe di codice richiede ormai millisecondi, ma validare, comprendere e manutenere quel codice richiede lo stesso tempo di prima, se non di più. Senza controllo, rischiamo di inondare i nostri repository di codice sintetico non compreso da chi lo rilascia.

La Spoon River del codice: quando il debito si trasforma in dissesto

Esiste un case study che ogni CTO dovrebbe conoscere a memoria per la sua chirurgica precisione nel dimostrare la pericolosità di un asset tossico. Il 1° agosto 2012, Knight Capital Group ha perso 440 milioni di dollari in soli 45 minuti.

La causa? Un frammento di codice obsoleto abbandonato in un router di trading, non rimosso perché “tanto non veniva utilizzato”.

La mancanza di code review, deployment verificati e monitoraggio in tempo reale ha spinto uno dei più grandi market maker di Wall Street al fallimento. Non è stato un attacco hacker, ma codice dimenticato che nessuno aveva il coraggio o la competenza di toccare.

Knight Capital dimostra come il debito tecnico ignorato può trasformarsi in una crisi finanziaria sistemica

Questo scenario si ripete a livello globale con impatti crescenti. Il 19 luglio 2024, un singolo aggiornamento difettoso di CrowdStrike ha bloccato ospedali, aeroporti e banche in tutto il mondo, mandando in crash 8,5 milioni di sistemi Windows.

Per le sole aziende Fortune 500, il danno economico ha superato i 5,4 miliardi di dollari. La causa? Un errore di accesso alla memoria, sfuggito a test automatizzati e processi di validazione rigorosi.

Il risultato è stato il più grande outage informatico della storia, con azioni legali miliardarie come quella da 500 milioni intentata da Delta Air Lines.

Il caso più emblematico per le imprese tradizionali resta quello di Southwest Airlines. Nel dicembre 2022, la compagnia ha cancellato oltre 16.000 voli nel picco festivo, lasciando a terra 2,5 milioni di passeggeri.

Il bilancio? Oltre 800 milioni di dollari di perdite e una multa record da 140 milioni. Il software di gestione equipaggi, vecchio di vent’anni, era stato aggiornato in modo frammentario nonostante il volume operativo fosse cresciuto del 69%.

La dirigenza aveva preferito investire nel frontend trascurando l’infrastruttura core, nonostante gli allarmi lanciati dal sindacato già nel 2015. Al primo imprevisto meteo, il sistema è collassato.

Se questi casi sembrano lontani dalla nostra realtà, ricordiamoci che per le PMI italiane ed europee il debito tecnico non si manifesta quasi mai con multe multimilionarie, ma con una condanna più subdola: l’immobilismo operativo. Nelle piccole e medie imprese in transizione digitale, l’asset tossico si traduce in un time-to-market rallentato all’inverosimile, nell’impossibilità di scalare e in un lock-in occulto.

Quante volte abbiamo visto aziende ostaggio di fornitori locali o di software house esterne che dettano unilateralmente tariffe e tempi perché nessun altro può comprendere il codice che hanno scritto? Senza una governance tecnologica interna e senza standard di qualità documentati, l’azienda cede di fatto la propria sovranità digitale al fornitore di turno. È una perdita silenziosa di margini che erode la competitività giorno dopo giorno.

In ognuno di questi scenari il problema non era l’ignoranza del rischio da parte del team tecnico, ma l’incapacità di tradurre quel rischio in metriche comprensibili e quantificabili per il CdA, che di conseguenza non ha ritenuto prioritario finanziarne la risoluzione.

Tradurre il silicio in finanza: le metriche DORA per il board

Esiste una categoria di metriche che gli sviluppatori monitorano con attenzione, ma che i vertici aziendali ignorano: la code coverage, il numero di bug risolti, i report di SonarQube o la percentuale di test automatici.

In alcuni team ci sono appositi task in pipeline il cui unico compito è quello di abbattere le segnalazioni SonarQube. In altri, il team di sviluppo si riunisce settimanalmente per discutere di come ridurre il Technical Debt Ratio. Tutti questi dati sono preziosi per gli ingegneri, ma non hanno alcun valore strategico per il business.

Presentarli al CdA per giustificare un budget di refactoring equivale a mostrare il tasso di usura dei bulloni delle turbine ai soci di una compagnia aerea: un dettaglio tecnico corretto, ma del tutto privo di valore strategico in quella sede.

Il framework DORA (DevOps Research and Assessment) rappresenta il ponte ideale tra la salute del codice e gli obiettivi di business. Validato su scala globale, mette in correlazione diretta l’efficienza dei processi tecnologici con le performance aziendali.

• Il Change Failure Rate, ovvero la percentuale di rilasci che causano incidenti in produzione. Questa metrica definisce l’affidabilità stessa del prodotto agli occhi del consiglio di amministrazione. Un valore alto indica che ogni nuova funzionalità rilasciata rappresenta una scommessa rischiosa che mina la fiducia dei clienti e aumenta il tasso di abbandono.
• Il Mean Time to Recovery, che calcola il tempo medio necessario per ripristinare il servizio a seguito di un disservizio. Rappresenta l’indice di resilienza dell’azienda: più veloce è il ripristino, minori saranno i danni economici diretti e l’impatto d’immagine sul brand.
• Il Lead Time for Changes, che misura il tempo richiesto per portare una singola riga di codice dall’ideazione all’ambiente di produzione. Questo indicatore coincide con il time-to-market, determinando la reattività commerciale dell’azienda rispetto ai competitor.
• La Deployment Frequency, che indica la frequenza dei rilasci stabili. Rilasciare in modo continuo e fluido testimonia un processo produttivo agile, che riduce le dimensioni dei singoli deploy e annulla i rischi sistemici tipici dei grandi rilasci cumulativi.

Se si presentano i dati con questo approccio, non si sta chiedendo del budget per “ripulire il codice”:

State presentando un piano di investimento, non state chiedendo di fare ordine

Si sta proponendo un investimento strategico con un ROI quantificabile e tempi certi. Questa è la differenza sostanziale tra chiedere e convincere: presentare i dati come miglioramenti misurabili della resilienza e della reattività del business, non come un intervento di manutenzione ordinaria.

Immaginate la scena. Voi parlate con passione di “refactoring del modulo di checkout” e il CFO, nella sua testa, sente solo: “mi stanno chiedendo soldi per rifare una cosa che funziona e questo abbasserà l’utile del 10%”. Provate allora a cambiare prospettiva: spiegate che questo intervento allunga di cinque anni la vita utile della piattaforma e ne aumenta il valore patrimoniale, gli occhi del CFO cambieranno luce: “quindi potrò avere altri 5 anni di ricavi ricorrenti da questo software senza doverlo sostituire?”.

Avete appena trasformato una spesa in un investimento capitalizzabile, ammortizzabile in più anni. Non state facendo pulizia; state ristrutturando le fondamenta dell’edificio aziendale.

La fabbrica del software: oltre l’estetica del codice

Spesso si fraintende il ruolo del CTO: la sua missione principale non è essere lo sviluppatore più talentuoso del team, ma progettare una “fabbrica di software sostenibile”. Si tratta di realizzare un sistema produttivo in grado di rilasciare valore in modo prevedibile, scalabile e resiliente nel tempo.

La qualità del codice non è un vezzo estetico, ma una scelta di governance.

I grandi progetti open source, come OpenJDK, dimostrano una verità controintuitiva: la rigidità degli standard e la severità dei processi non frenano lo sviluppo. Al contrario, sono l’unica condizione che permette a centinaia di sviluppatori di collaborare in modo sicuro.

Nel TCO del codice scadente c’è una voce invisibile: il costo dell’onboarding. Inserire nuove risorse in un codebase privo di documentazione o code review aumenta la complessità senza far crescere la produttività.

Ho vissuto sulla mia pelle domande di manager che chiedevano: “Perché non possiamo semplicemente aggiungere altre persone al team per accelerare lo sviluppo?”. Come consulente ero sempre combattuto sul come poter presentare la questione in modo chiaro e convincente: il progetto era estremamente complesso e aggiungere persone avrebbe aumentato il rischio di regressioni e rallentato il rilascio. Ma come spiegare questo concetto a chi non ha mai scritto una riga di codice in vita sua?

Gira da anni una storia che illustra bene questo concetto: un team di sviluppo di 10 persone impiega 10 giorni per completare un modulo software. Aggiungendo altre 10 persone, il tempo necessario per completare lo stesso modulo non scende a 5 giorni, ma sale a 15. Perché? Perché le nuove risorse impiegano più tempo a capire cosa fare e come farlo e devono essere seguite da chi già conosce il progetto. Il risultato è un rallentamento complessivo, non un’accelerazione.

L’esito inevitabile del debito accumulato è la riscrittura da zero, che spesso viene vista come l’unica soluzione possibile. In realtà, la riscrittura è un’eccezione, non la regola, e se all’interno dell’azienda non cambiano i processi, il nuovo software sarà destinato a diventare un nuovo asset tossico in pochi anni.

Ricordo un’azienda che aveva stratificato modifiche per anni. Per aggiornare il prodotto, si rese necessario ricostruire tutto da capo perché linguaggi e dipendenze erano obsoleti e insicuri. Un lavoro di anni è stato condensato in sei mesi, tenendo solo il necessario e adottando un’architettura scalabile.

Ma questa è l’eccezione. Spesso manca la forza finanziaria per farlo, e si continua a rattoppare sperando che il castello non crolli. I costi finali del ritardo, come insegna Southwest (che ha speso un miliardo di dollari per rimediare), sono da tre a cinque volte superiori rispetto alla manutenzione ordinaria.

Il problema di fondo non era la mancanza di budget o di competenze, ma un difetto di traduzione: il rischio operativo era noto ma non è stato comunicato con il lessico adatto a generare il senso di urgenza necessario a livello decisionale.

Audit, misura e strategia per la tua organizzazione

Come leader tecnologici (CTO o tech lead), avete tre responsabilità non delegabili che definiscono il vostro ruolo in chiave manageriale, trasformandovi da responsabili operativi a gestori strategici del rischio. La prima consiste nell’imporre elevati standard di qualità come precondizione per la scalabilità del team di sviluppo, poiché ogni scorciatoia rappresenta un costo occulto che l’azienda pagherà in futuro. La seconda è l’adozione sistematica della code review come strumento per condividere la conoscenza e mitigare il Key Person Risk, considerando ciascuna revisione come una misura preventiva di business continuity. La terza è la rendicontazione dello stato di salute del software attraverso metriche allineate a quelle aziendali: indicatori concreti che colleghino le scelte architetturali agli outcome di business.

Quando presentate una richiesta di budget per ristrutturare un’applicazione legacy, evitate di promettere un “codice più ordinato”. Impegnatevi a dimezzare il CFR o a contrarre il Lead Time per Changes del 30%, portando dati a supporto della vostra tesi.

Domattina, o comunque entro questa settimana, provate a compiere queste azioni concrete all’interno del vostro dipartimento IT:

• Avviate una mappatura interna: individuate il modulo software critico che costituisce un potenziale Single Point of Failure (SPOF).
• Stimate l’impatto economico: calcolate il costo di un downtime prolungato su quella componente, traducendolo in perdita di fatturato e costi di ripristino.
• Preparate la presentazione: mostrate alla direzione questi dati precisi al posto del classico debito tecnico.

Smettete di chiedere il permesso per fare bene il vostro lavoro

Dimostrate invece che la stabilità e la qualità dello sviluppo sono esattamente gli obiettivi che il business vi richiede, anche quando i vertici non ne sono ancora del tutto consapevoli.