“Lo sistemiamo dopo”: la bugia più costosa dello sviluppo software

“Lo sistemiamo dopo.” “In questo momento non abbiamo tempo.” “Appena possibile lo rifacciamo come si deve.”

Nel mondo del software queste frasi sono fin troppo familiari. A prima vista sembrano persino ragionevoli: c’è una scadenza imminente, un cliente da non perdere, un mercato che non aspetta. Per giustificare l’ennesima scorciatoia, entra così in scena l’etichetta elegante che l’industria si è costruita nel tempo: debito tecnico.

Il problema è che, nella pratica quotidiana, questa narrativa finisce spesso per trasformarsi in un alibi. L’idea di “prendere un prestito” sul futuro viene accettata come se bastasse una promessa implicita a garantire che quel futuro arriverà davvero, ordinato, con tempo, risorse e budget dedicati. Nella maggior parte dei casi, però, quel futuro non arriva mai. E il debito, come ogni debito, cresce: non in modo astratto, ma in ore sprecate, bug ricorrenti, frustrazione, perdita di velocità e progressiva fuga dei talenti.

Il costo invisibile che sta consumando le aziende

Quando si parla di debito tecnico, il rischio più comune è ridurlo a una questione puramente estetica, come se si trattasse soltanto di “codice brutto”. In realtà il problema è prima di tutto economico e operativo. Secondo una ricerca di Sonar, per un progetto da un milione di linee di codice il costo attribuibile al debito tecnico può arrivare a circa 306.000 dollari l’anno, equivalenti a 5.500 ore di lavoro di sviluppo bruciate in attività di rimedio invece che in innovazione (fonte).

Il Consortium for Information & Software Quality (CISQ) arriva a quantificare l’impatto complessivo del debito tecnico software in circa 1,52 trilioni di dollari, all’interno della più ampia stima sul costo della scarsa qualità del software (report PDF 2022).

McKinsey descrive un quadro che molti CIO riconoscono immediatamente: il debito tecnico può arrivare a pesare intorno al 40% dei budget IT, e una parte significativa delle risorse destinate all’innovazione viene assorbita dalla manutenzione straordinaria (fonte; per una misura e una tassonomia del fenomeno, si veda anche questo approfondimento). Il dato più preoccupante, però, non è la cifra in sé, ma ciò che rappresenta: tempo sottratto al futuro, opportunità rimandate fino a trasformarsi in occasioni perse, innovazione che resta bloccata invece di accelerare.

Il ciclo vizioso che quasi nessuno vuole nominare

Il debito tecnico raramente si manifesta come un evento improvviso. Più spesso entra in modo graduale, accompagnato da giustificazioni apparentemente ragionevoli, seguendo uno schema ricorrente.

All’inizio tutto si riduce a una promessa facile. Si spedisce rapidamente, magari con codice fragile scritto sotto pressione, con l’idea che “nella prossima iterazione” verrà sistemato. È un patto implicito: oggi velocità, domani pulizia.

Col tempo, però, il codice diventa un campo minato. Ogni modifica coinvolge più parti del sistema, ogni correzione introduce nuovi problemi, anche le funzionalità più semplici richiedono discussioni interminabili perché nessuno si fida più davvero della base esistente. È il momento in cui diventa chiaro che la scorciatoia non era tale, ma un tunnel.

A quel punto l’intero processo rallenta. In media, una quota rilevante dello sforzo di sviluppo finisce assorbita dalla gestione di problemi generati dal debito tecnico: ciò che prima richiedeva un giorno inizia a richiederne cinque, e la velocità inizialmente guadagnata viene ripagata con interessi elevatissimi.

La fase più costosa, e spesso la più sottovalutata, riguarda il morale. Gli sviluppatori smettono di costruire e iniziano a rattoppare. Il lavoro diventa una forma di sopravvivenza tecnica più che di progresso. Quando la qualità del lavoro perde dignità, i profili migliori iniziano a guardarsi intorno, riconoscendo ambienti in cui la complessità viene lasciata marcire.

Chi arriva dopo eredita un sistema difficile da comprendere e ancora più difficile da spiegare. Nuovi strati vengono aggiunti sopra una base già fragile, alimentando la spirale. A un certo punto emerge la frase che sembra inevitabile: “Dobbiamo riscrivere tutto”.

Il problema è che la riscrittura, nella maggior parte dei casi, fallisce. Non perché sia impossibile in teoria, ma perché arriva quando l’organizzazione è già sotto pressione: tempi stretti, concorrenza aggressiva, capitale politico esaurito, competenze disperse. In quelle condizioni, riscrivere non è una strategia, ma una scommessa.

Il caso Netscape: quando il debito tecnico uccide un gigante

La vicenda di Netscape Navigator è diventata emblematica proprio per questo motivo. Nel 1998 Netscape dominava il mercato dei browser con circa l’80% di quota. Il prodotto funzionava, ma il codice era fragile e sempre più difficile da sostenere, mentre Internet Explorer guadagnava terreno.

La risposta del management fu drastica: riscrivere tutto da zero. Joel Spolsky, in un noto articolo, descrisse quella decisione come “il singolo peggior errore strategico che un’azienda software possa fare” (il ragionamento più generale è in Things You Should Never Do, Part I). Al di là della formula, il meccanismo è chiaro: la riscrittura bloccò Netscape per anni, mentre i concorrenti continuarono ad avanzare. Quando il nuovo browser arrivò, era lento, pieno di bug e ormai fuori tempo massimo. La quota di mercato era crollata e, nel 2008, AOL annunciò la fine del supporto ai prodotti Netscape.

La tragedia non sta nel tentativo fallito, ma nel fatto che la riscrittura venne presentata come una scelta razionale, quando in realtà era il risultato di anni di debito accumulato e mai affrontato. Non salvò tempo né denaro: fu un prestito sul futuro con un tasso d’interesse insostenibile.

La verità che nessuno vuole sentire

Molte organizzazioni faticano ad ammetterlo, ma il debito tecnico “intenzionale” raramente viene ripagato come promesso. Non per mancanza di buona volontà, bensì perché il contesto non incentiva il ripagamento. C’è sempre qualcosa di più urgente: una nuova funzionalità, una richiesta commerciale, una crisi, una scadenza. “Più avanti” diventa così un orizzonte che si sposta continuamente.

È un fenomeno coerente con quanto rilevato da diverse analisi di settore: finché l’azienda regge, ogni incentivo spinge a rimandare. Quando non regge più, spesso è troppo tardi per intervenire senza conseguenze dolorose. In questo senso, “debito tecnico” diventa una formula comoda per rendere presentabile una realtà scomoda: decisioni sbagliate che non si vogliono chiamare per nome. Un errore viene trasformato in strategia, e una strategia, almeno sulla carta, sembra sempre un piano.

I team che funzionano fanno scelte diverse

Esistono team in grado di spedire rapidamente senza sacrificare la qualità. Non perché siano eccezionali, ma perché trattano la qualità come parte integrante della velocità. Dispongono di standard chiari, pratiche consolidate, revisioni serie, test affidabili e una definizione condivisa di cosa significhi davvero “pronto”.

È vero che, nelle fasi iniziali, questi team possono impiegare un po’ più di tempo. Quel 10 o 20% in più che spesso viene percepito come un lusso. Ma evitano mesi passati a districare problemi, non perdono competenze chiave e non sono costretti a fermare tutto per riscrivere dopo pochi anni. Nel lungo periodo la matematica è impietosa: i costi dovuti al debito tecnico possono arrivare a 1,5 milioni di dollari in cinque anni per un milione di linee di codice, equivalenti a 27.500 ore di lavoro di sviluppo (Sonar).

Esistono eccezioni? Sì, ma devono restare tali

Ci sono contesti in cui un compromesso può avere senso: prototipi destinati a essere scartati, demo per validare un’ipotesi, esperimenti con un orizzonte limitato. Anche in questi casi, però, il debito dovrebbe essere esplicito, circoscritto, documentato e associato a un piano di rimedio immediato.

Ward Cunningham, che coniò il termine nel 1992, lo spiegò chiaramente: spedire codice in fretta è come indebitarsi. Il debito può accelerare lo sviluppo solo finché viene ripagato prontamente. Non “quando ci sarà tempo”, non “nel prossimo trimestre”, ma prontamente.

Le domande scomode che andrebbero poste

Prima di accettare consapevolmente debito tecnico, alcune domande dovrebbero essere inevitabili.

• Quando verrà ripagato, esattamente? Se la risposta è vaga, non è un piano.
• Chi può davvero fermare nuove funzionalità per ripagarlo? Se non esiste un’autorità chiara, è improbabile che accada.
• Qual è il piano concreto di rimedio? Senza una roadmap, non è una strategia: è una speranza.
• Cosa accade se non viene ripagato? Se la conseguenza non è chiara, il rischio è sottostimato per definizione.

Conclusione

Il debito tecnico non è un destino inevitabile, ma una scelta. E come ogni scelta, produce conseguenze che prima o poi presentano il conto.

Da un lato c’è la ricerca della velocità immediata, l’accumulo di complessità, il rallentamento progressivo e, infine, la necessità di fermarsi per riscrivere mentre la concorrenza avanza. Dall’altro c’è la decisione di costruire bene fin dall’inizio: forse più lentamente nelle prime fasi, ma in modo nettamente più rapido e sostenibile nel lungo periodo, con team abituati a costruire invece che a rattoppare e prodotti in grado di evolvere senza collassare sotto il proprio peso.

In estrema sintesi, un progetto può essere costruito bene la prima volta o costretto a essere costruito due volte. “Lo sistemiamo dopo” resta una delle frasi più costose che l’industria del software continui a ripetersi: non una strategia, ma un fallimento organizzativo mascherato da scelta razionale.

Print Friendly & PDF Download