Il post in tre frasi
Padre Paolo Benanti scrive su Il Sole 24 Ore che il debito tecnico un tempo era una scelta consapevole, con una scadenza annotata da qualche parte: non è mai stato così e chi ha coniato la metafora dice il contrario.
Qualcosa di deliberato, stimato e datato esiste davvero, ma è l’elenco delle funzioni rinviate (un backlog, non una passività). Confondere le due cose fa passare una scorciatoia sulla qualità per una scelta consapevole.
La seconda premessa, secondo cui sviluppo e manutenzione sono due fasi in sequenza, è sbagliata allo stesso modo. Il problema che emerge è di natura ingegneristica prima ancora che manageriale o contabile.
Padre Paolo Benanti ha scritto su Il Sole 24 Ore del 12 agosto, nella rubrica “Etica di frontiera”, un articolo sui costi del software: “I costi del software: far emergere ciò che il mercato non prezza”.
Le due principali affermazioni su cui l’articolo si regge sono errate. Non sono dettagli secondari: sono le premesse da cui parte tutto il ragionamento. Credo valga la pena fare qualche puntualizzazione per i lettori, perché non si possono costruire analisi solide partendo da una linea di partenza errata.
Un debito che quasi nessuno delibera
La prima affermazione è questa:
Il debito tecnico, nel lessico dell’ingegneria, era un debito contratto con cognizione di causa: si accettava una soluzione imperfetta sapendo che un giorno sarebbe andata rifatta, e la scadenza restava iscritta da qualche parte.
Non è così, e non si tratta di una questione di parole.
Facciamo un passo indietro, per chi non ha familiarità con il termine. “Debito tecnico” è una metafora contabile. Definisce la distanza tra il software com’è e come dovrebbe essere, per renderlo più facile da gestire e da far evolvere. Quella distanza è passività e, come un debito vero, si paga con gli interessi. Gli interessi sono il tempo aggiuntivo necessario per ogni modifica successiva: ogni funzione aggiuntiva costa di più, ogni difetto è più difficile da individuare, ogni nuova persona impiega più tempo per capire come funziona il sistema.
Per lo stesso concetto esistono altri termini, come il degrado del progetto e l’entropia del software, che però descrivono il sintomo visibile nel codice. La metafora contabile indica la passività e il suo interesse, ossia ciò che serve a chi deve prendere decisioni. Come quella distanza si sia formata, invece, la metafora non lo stabilisce. Stabilisce che cosa costa averla.
Il debito tecnico che oggi si osserva nelle imprese nasce da investimenti mancati, da progetti fatti male, da scelte tecniche improvvide, da competenze che non c’erano nel momento in cui servivano. Che la scorciatoia si veda mentre la si prende è persino probabile; ciò che quasi mai avviene è deliberarla come debito, cioè stimarne il costo, scriverlo e trovare qualcuno che se ne assuma la responsabilità. È una jattura, non una strategia.
Non lo dice solo la letteratura. In un suo commento pubblicato su CIO, rivista rivolta ai responsabili dei sistemi informativi, nel marzo di quest'anno Rebecca Fox (oggi fondatrice di una società di consulenza, in passato Group CIO di un gruppo internazionale di cybersicurezza e tecnologia) ripercorre come si è formato il patrimonio applicativo delle imprese: ondate successive di trasformazione digitale, introduzione di nuove piattaforme rivolte ai clienti, adozione di SaaS, “livelli di integrazione cuciti insieme sotto pressione”; poi il Covid, con tecnologia messa in campo alla velocità necessaria a tenere in vita l’azienda. “Gran parte di quel patrimonio non è mai stata consolidata.” Il risultato è fragile: costoso da far girare, difficile da cambiare, poco affidabile quando il carico cresce. In quel racconto ci sono scelte al risparmio, ma nessuna è la deliberazione di un debito: nessuno ne ha stimato il costo di rientro, l’ha messo per iscritto e se n’è assunto la responsabilità.
Ridurre il perimetro non è contrarre un debito
Resta una domanda: se il debito quasi mai si delibera, che cosa si fa quando il tempo non basta? Le variabili in gioco sono tre: la data, le risorse e l'elenco delle funzioni. L'ultima è quella che interviene più spesso. Si riduce il perimetro, decidendo che cosa entra nel primo rilascio e che cosa si rimanda al successivo. È la logica del prodotto minimo funzionante (MVP) e del backlog.
Qui sta l’equivoco che genera la premessa di Benanti. Qualcosa deliberato con cognizione di causa, stimato, messo per iscritto e dotato di una scadenza esiste davvero: è l’elenco delle funzioni rinviate e da sviluppare. Vive nel backlog e nella roadmap; si discute nelle riunioni di prodotto; ha un proprietario e una data. Ma quell’elenco non è né una passività né una soluzione imperfetta che qualcuno ha accettato: è la parte del prodotto che si è deciso di costruire in seguito. Benanti associa al debito tecnico il significato che appartiene alla pianificazione e ne ricava una figura che nel lavoro reale non si incontra: il debito consapevole, stimato e datato.
La differenza non è terminologica. Rinviare una funzione significa consegnare un prodotto che fa meno cose, fatte bene: ciò che manca è funzionalità e ciò che si consegna ha la qualità richiesta a un sistema in esercizio. Contrarre un debito tecnico significa consegnare le stesse cose, fatte peggio di come andrebbero fatte: ciò che manca è la qualità interna e il conto non arriva sotto forma di una funzione assente, ma sotto forma di costi aggiuntivi per ogni futura modifica. Nel primo caso non matura alcun interesse; nel secondo l’interesse è l’unica cosa certa.
Confondere le due cose ha una conseguenza pratica precisa. Se si crede che il modo legittimo di andare veloci sia accettare una soluzione imperfetta, si autorizza la scorciatoia sulla qualità e le si dà il nome di “disciplina”. Se si sa che il modo legittimo è consegnare meno, si tratta sull’elenco delle funzioni e la qualità di ciò che si consegna smette di essere negoziabile. Sono due conversazioni diverse fra chi costruisce e chi decide. E producono due sistemi diversi.
Cosa aveva scritto davvero Cunningham
Anche la ricostruzione storica è rovesciata.
L’espressione di Benanti da cui conviene partire è “la scadenza restava iscritta da qualche parte”. Nella metafora originale non c’è e vale la pena risalire alla fonte per vedere perché. Nel testo del 1992, Cunningham descrive il metodo del proprio gruppo: si parte da un prototipo funzionante e si cresce per incrementi, consegnando presto codice ancora acerbo e consolidandolo subito dopo, con riscritture ripetute delle sezioni da migliorare. La consegna anticipata è il momento in cui si contrae il debito, mentre il consolidamento è il modo ordinario per estinguerlo. Il pericolo che Cunningham segnala sta nel non consolidare, nel failure to consolidate, nel debito che nessuno ripaga, negli interessi che si pagano per ogni minuto speso a lavorare con codice di scarsa qualità. Benanti presenta, come scelta deliberata ex ante, ciò che in Cunningham è un fallimento ex post: il consolidamento che non si è verificato.
Per Cunningham si decide una sola cosa: quando consegnare. Che cosa ci sarà da correggere in ciò che si è consegnato si scopre dopo, lavorandoci, valorizzando una comprensione del problema che al momento della consegna non esisteva ancora. Anche il tempo di rientro è diverso da come Benanti lo descrive: si ripaga subito, con un consolidamento continuo. Nessuna scadenza è annotata da nessuna parte.
Nel 2009, vedendo come la metafora era stata letta, Cunningham è tornato sull’argomento in un video di cinque minuti. Dice di non essere mai stato favorevole a scrivere codice male e di essere invece favorevole a scrivere codice che rifletta la comprensione attuale del problema, anche quando quella comprensione è parziale.1 La lettura corrente, con codice scadente oggi in cambio di una promessa di rifacimento per domani, è proprio quella che ha respinto. E indica la condizione che rende praticabile tutto il resto: poter ripagare il debito dipende dall’aver scritto codice abbastanza pulito da poter essere rifattorizzato.
Tanto basta a chiudere la questione della premessa storica. La definizione che Benanti attribuisce al lessico dell’ingegneria non è quella di chi l’ha introdotto, e per accorgersene non serve altro che il testo originario.
Quattro modi di indebitarsi, non uno
Nello stesso 2009, Martin Fowler prende atto di ciò che, nel frattempo, era accaduto nell’uso corrente. Il termine si applicava a qualunque difetto di progetto: codice scritto male, scorciatoie adottate sotto pressione, sistemi lasciati deteriorare. C’era chi chiedeva di riservare il termine alle sole scelte ponderate, escludendo il codice scritto male da chi non conosce le buone pratiche. È la restrizione che Benanti dà per acquisita, con una differenza non piccola: chi la proponeva sapeva di proporla. Fowler risponde che la domanda è mal posta e, invece di restringere il campo, lo struttura.
Confronta due domande indipendenti. La prima: il debito lo hai visto arrivare, oppure no? La seconda: la scelta era ragionevole o avventata?
Un debito può essere visto e avventato: il team conosce le pratiche corrette e sceglie comunque la scorciatoia, convinto di non potersi permettere il tempo per fare le cose per bene. Può essere non visto e avventato: sono i team che ignorano le buone pratiche di progettazione e accumulano problemi senza sospettarlo. Può essere non visto e ragionevole, ed è il caso che Fowler attribuisce ai team migliori: il progetto è fatto bene, il codice è pulito, e può volerci un anno di lavoro prima di capire quale sarebbe stato il progetto giusto. Fowler aggiunge che questo tipo di debito non è solo comune, ma inevitabile proprio per i team che progettano bene e, come tale, va messo in conto. E può essere visto e ragionevole: un compromesso pesato, con il costo del rientro valutato prima di accettarlo. Le prime due caselle insieme — il debito avventato, che il team lo veda arrivare o no — sono, aggiungo io, la gran parte di ciò che si incontra nelle imprese.
Il caso non visto e ragionevole merita una nota, perché Fowler lo attribuisce esplicitamente a Cunningham: è, scrive, il tipo di debito di cui Ward parla nel suo video. Chi ha costruito la classificazione colloca dunque l’autore della metafora fuori dalla casella che Benanti presenta come l’unica esistente.
Solo il caso visto e ragionevole corrisponde alla descrizione di Benanti, che però chiede di più di quanto chieda Fowler: non solo un compromesso ponderato, ma anche una scadenza iscritta da qualche parte. Ed è in quella forma che quasi non si incontra. Perché si verifichi, qualcuno deve aver stimato in anticipo quanto costerà rimettere le cose a posto, deve averlo messo per iscritto, e l’organizzazione deve poi trovare il tempo e il denaro per farlo.
C’è poi una ragione per cui quella casella, già poco popolata, difficilmente si popolerà. Consegnare deliberatamente software di bassa qualità è qualcosa che si può dire a voce, non per iscritto. Il quadro normativo europeo si sta muovendo nella direzione opposta. Da dicembre 2026, la nuova direttiva sulla responsabilità per il danno da prodotti difettosi considera il software un prodotto a tutti gli effetti, stabilisce che una vulnerabilità di cibersicurezza può renderlo difettoso e toglie al produttore la difesa del difetto sopravvenuto quando dipende dal software, dai suoi aggiornamenti o dalla loro mancanza, se il prodotto è rimasto sotto il suo controllo. A partire da dicembre 2027, il Cyber Resilience Act richiederà che un prodotto con elementi digitali sia messo a disposizione sul mercato senza vulnerabilità sfruttabili note, sulla base di una valutazione dei rischi che il fabbricante è tenuto a documentare. Un debito contratto con cognizione di causa, stimato, messo per iscritto e datato è, in un contenzioso, un elemento a sfavore del produttore.
L’articolo smentisce se stesso
L’argomento più netto non ha bisogno di alcuna fonte esterna.
L’articolo si apre descrivendo “librerie di genomica nate come appendice di un articolo, mantenute a tempo perso, spesso incapaci di installarsi su una macchina nuova”. Quello è lo stato delle cose prima dell’arrivo degli agenti di intelligenza artificiale. Debito non deliberato, non segnato da nessuna parte, senza un proprietario, accumulato in decenni di ricerca.
Due paragrafi più avanti si legge che, in precedenza, il debito era deliberato e aveva una scadenza. L’esempio con cui il pezzo si apre smentisce la premessa storica su cui si regge.
Risanare non è procedere per incrementi
Recuperare il debito tecnico e lavorare in modo incrementale sono due attività distinte che richiedono approcci diversi.
Consolidare mentre si procede fa parte del lavoro ordinario: è la quota di capacità che ogni iterazione nel ciclo di sviluppo dedica a rimettere in ordine ciò che il giro precedente ha rivelato essere carente. Rientrare da un debito accumulato per anni è un’altra cosa. È un risanamento: assorbe risorse senza produrre nuove funzioni, impone di rallentare e va discusso esplicitamente con chi decide i budget.
Un’organizzazione che crede di essere agile mentre accumula debito ha un problema che non vede. Chiamare “scelta con cognizione di causa” ciò che è avvenuto per disattenzione o per cattive pratiche è miope e controproducente.
Sviluppo e manutenzione: un processo che esiste solo sulla carta
La seconda affermazione è duplice. Da un lato:
Gli stessi ricercatori osservano che il collo di bottiglia non è più scrivere ma validare, e che gli agenti si dichiarano sicuri anche quando consegnano errori evidenti: il giudizio resta compito umano.
Dall’altro, tre paragrafi prima:
Il prezzo della fabbricazione è sceso quasi a zero; quello della manutenzione è rimasto dov’era, perché è fatto di attenzione umana, e l’attenzione umana non ha subito alcuna deflazione.
Le due affermazioni non stanno insieme perché Benanti associa di fatto la validazione alla manutenzione. Lo dice lui stesso: il prezzo della manutenzione è rimasto dov'era “perché è fatto di attenzione umana”, e della validazione scrive che “il giudizio resta compito umano”. Ma verificare e collaudare fanno parte dello sviluppo. Se il collo di bottiglia è la validazione, allora rientra nella “fabbricazione”. E una “fabbricazione” con un collo di bottiglia non costa quasi zero.
Il problema ha tre livelli di gravità crescente.
Il primo: sviluppare software non significa solo scrivere codice. Vuol dire capire un problema e concordare ciò che serve davvero: progettare l’architettura del sistema; farlo dialogare con i programmi e le procedure che l’azienda già utilizza; verificarlo e collaudarlo; metterlo in esercizio e far lavorare insieme le persone coinvolte nelle diverse attività. La scrittura del codice è una parte e, in molti progetti industriali, non è nemmeno la più grande. Un’affermazione sul prezzo della “fabbricazione” che si limita alla sola scrittura considera un pezzo e lo presenta come il totale.
Il secondo: il costo non è sparito e se ne è aggiunto un altro. I programmatori non sono usciti dal libro paga. Nella migliore delle ipotesi, è aumentata la loro produttività nella scrittura del codice, il che non equivale affatto all’azzeramento del prezzo. E a quella spesa se ne è affiancata una nuova, misurata a consumo, che le imprese non sanno ancora preventivare: in un’indagine McKinsey di maggio 2026 su settantacinque rispondenti qualificati, il 93% dichiara di aver superato il budget previsto per l’AI.2 E poi c’è il costo indiretto, che è il più insidioso: il codice generato in fretta e rivisto male ritorna sotto forma di guasti in produzione, cioè di debito tecnico. È la storia dell’ingegnere senior che ho raccontato qui pochi giorni fa: sette mesi dall’entusiasmo per il lavoro che si fa in due giorni invece che in una settimana, fino al capo che gli prospetta il licenziamento al terzo crash in produzione. Ne ho scritto più volte, discutendo dei costi nascosti dell'AI, che includono la qualità del codice prodotto, il tempo di revisione umana ancora necessario e la riprogettazione dei processi che l'adozione richiede. E ci sono tornato sulla differenza fra coding e ingegneria del software. Le voci di spesa si sono moltiplicate e sono diventate più difficili da individuare nel bilancio.
Il terzo: sviluppo e manutenzione non sono due fasi in sequenza. Che l’articolo le disponga in sequenza non è una mia illazione: la manutenzione vi compare come l’onere di “tenere insieme l’oggetto quando l’entusiasmo della fabbricazione è finito”. Prima si “fabbrica”; poi, finito quello, qualcuno tiene in piedi.
Anche la parola “manutenzione” porta con sé un’immagine errata: quella della riparazione. Il termine nasce insieme al ciclo di vita a cascata, in cui c’è un prodotto finito da mantenere in efficienza, e le categorie in cui si articola — correttiva, adattativa, perfettiva, preventiva — lavorano tutte entro un perimetro sostanzialmente costante: si corregge, si adatta, si migliora ciò che già c’è.
Che quel contenitore fosse troppo stretto si è visto subito. Nel 1980 Bennet Lientz e Burton Swanson pubblicano un’indagine su 487 organizzazioni: circa la metà dell’impegno di manutenzione va in interventi perfettivi — migliorie richieste dagli utenti, documentazione, ottimizzazioni — e circa un quarto in interventi adattativi, cioè adeguamenti all’ambiente in cui il sistema gira. Alla correzione dei difetti resta ancora circa un quinto. Già allora, in ciò che si chiamava manutenzione, quasi quattro quinti del lavoro non erano dedicati alla correzione dei difetti.
Il vocabolario si è mosso di conseguenza. Da un lato lo standard ISO/IEC/IEEE 14764, che eredita la classificazione proposta da Swanson nel 1976, ha continuato ad allargarsi: nell’edizione del 2022 compare la manutenzione additiva, quella che aggiunge funzioni. Dall’altro, e conta di più, la disciplina ha smesso di chiamare manutenzione ciò che non lo è: oggi si parla di evoluzione del software. I termini in gioco non sono due ma tre: lo sviluppo; la manutenzione, che tiene in efficienza un perimetro dato; l’evoluzione, che quel perimetro lo cambia, con nuove funzioni e nuove architetture, fino a sistemi che nell’arco degli anni diventano altro da ciò che erano. L’articolo ne usa due e il terzo è quello che dura quanto il sistema. Chiamare tutto questo “tenere insieme l’oggetto quando l’entusiasmo della fabbricazione è finito” significa scambiare il tutto per il quinto della manutenzione che riguarda la correzione dei difetti, ed escludere l'evoluzione.
Distinguere tra sviluppo, manutenzione ed evoluzione consente di definire diverse tipologie di intervento. Lo facciamo tutti: io, per primo, quando insegno e scrivo. Si presentano prima le attività di costruzione, poi quelle di modifica a perimetro dato e, infine, quelle di evoluzione, ed è un modo ragionevole per introdurre la materia a chi la incontra per la prima volta.
Quella visione in sequenza ha una funzione didattica e non descrive come quelle attività si declinino nei processi reali (la parte di ogni corso di ingegneria del software che tratta di cicli di vita e di processi software). Sono considerazioni note da decenni. Il software non si sviluppa secondo un ciclo a cascata. È un approccio che sopravvive in casi particolari, nei sistemi regolati e in quelli critici, dall’avionica ai dispositivi medici, dal controllo industriale ai sistemi embedded in tempo reale, dove, peraltro, assume forme più articolate, come il V-Model. In questi casi è una scelta deliberata, giustificata dal rischio, non l’impostazione ordinaria del lavoro. E non è un mondo statico: un sistema avionico subisce modifiche per tutta la sua vita operativa. Quello che è rigido è la procedura con cui ogni cambiamento viene approvato e certificato, non l’assenza di cambiamenti. Anche nel caso più favorevole all’argomento di Benanti, l’evoluzione è continua.
L’idea che il software venga prima “fabbricato” e poi, in un momento successivo e separato, mantenuto è stata discussa e smentita a partire dagli anni Ottanta. Nel 1980, Manny Lehman pubblica le sue leggi sull’evoluzione del software: la prima afferma che un programma riflette una realtà esterna, cambia di continuo o diventa via via meno adeguato.3 Nel 1986 Barry Boehm propone il modello a spirale e già il titolo del suo lavoro tiene insieme le due cose che l’articolo separa: “A Spiral Model of Software Development and Enhancement”, un modello a spirale per lo sviluppo e il miglioramento del software. Nella spirale non c’è un momento in cui si smetta di costruire e si cominci a mantenere. C’è il giro successivo, che ripete le stesse attività su una versione più matura del sistema.
Da allora, la pratica si è mossa nella stessa direzione e molto più in fretta della divulgazione: sviluppo evolutivo, metodi agili, rilasci frequenti a piccoli passi, automazione della messa in esercizio, DevOps. Tutto ciò che un’azienda che sviluppa software fa ogni giorno presuppone che la costruzione e l’evoluzione siano un unico flusso di lavoro, con le stesse persone e gli stessi strumenti. DevOps, in particolare, nasce per abbattere il muro fra chi costruisce e chi tiene in funzione, perché quel muro comportava costi per i quali nessuno si assumeva la responsabilità.
Usare la distinzione a fini definitori per introdurre i concetti va benissimo. Usarla senza poi rileggerla in un processo reale e continuo porta a una rappresentazione distorta della realtà.
La conclusione eredita l’errore
A questo punto, qualcuno potrebbe obiettare che la conclusione dell’articolo, in fondo, è ragionevole e che le puntualizzazioni sono pignoleria.
Vediamola, allora, questa conclusione. Benanti chiede “un proprietario riconoscibile per ogni artefatto critico”, “un piano di manutenzione credibile come condizione dell’adozione e non come dettaglio successivo”, “l’attribuzione trattata come categoria seria e non come cortesia accademica”, “forme di apprendistato ricostruite attorno alla verifica”. Il punto non è se siano condivisibili. È che sono generiche e quindi a metà tra l’ovvio e l’inutile: misure che si potrebbero scrivere senza aver letto il problema, valide per qualunque azienda in qualunque momento, che non dicono a chi decide che cosa fare diversamente da ieri. Su un quotidiano economico, per lettori che quelle pagine usano per farsi un’opinione, un elenco che vale sempre e ovunque non vale nulla.
Il guaio, però, non si limita all’elenco. Nel tempo, le decisioni si prendono in base allo schema mentale che ha portato alla conclusione. Peter Senge, in La quinta disciplina, chiama modelli mentali le assunzioni radicate, le generalizzazioni e le immagini con cui interpretiamo il mondo e in base alle quali agiamo, e osserva che le idee nuove non entrano nella pratica quando entrano in conflitto con tali modelli. Se il modello è incoerente, produce scelte sbagliate appena si esce dal caso in cui aveva fornito una raccomandazione anche condivisibile.
Qui il modello è incoerente in due punti. Se si ritiene che il debito tecnico sia una scelta consapevole, per non contrarlo basterebbe “decidere meglio” visto che tutto sarebbe noto. Poiché quella conoscenza spesso non c’è e, quando c’è, quasi mai si traduce in una deliberazione, serve invece un ripensamento profondo delle competenze e delle modalità con cui si pianifica e si sviluppa un prodotto. Se si ritiene che esistano una fase di “fabbricazione” e poi solo una di manutenzione, si redigono contratti, budget e organigrammi attorno a due momenti che, nel lavoro reale, costituiscono un unico processo evolutivo continuo.
La linea di partenza da cui Benanti ricava tutto, quindi, non è mai esistita, ed è questa la correzione che conta di più. E il ragionamento non è nemmeno implicito: l’articolo oppone un imperfetto a un presente — il debito tecnico “era un debito contratto con cognizione di causa”, mentre “ciò che nasce adesso è un debito che nessuno delibera” — e ne ricava che l’intelligenza artificiale abbia peggiorato le cose. Se fosse così, la risposta ragionevole sarebbe recuperare la disciplina perduta.
Ma quel “prima” non c’è mai stato. Il debito è sempre stato in gran parte involontario e gli agenti non hanno introdotto una malattia nuova: hanno creato l’illusione di poter produrre più software a costo zero. Ora si producono più linee di codice e se ne accumulano molte di più. Questa conclusione è più dura di quella di Benanti, perché sostiene che non esiste alcuna età dell’oro a cui tornare e che i problemi da affrontare sono di natura ingegneristica prima che contabile o puramente manageriale.
Il patrimonio dell’ingegneria del software su questi temi è vasto e facilmente accessibile. Conviene attingervi prima di trarre conclusioni, soprattutto scrivendo per chi le userà per decidere.
Ringrazio Cristian Mesiano per i commenti puntuali su una versione preliminare di questo testo.
Questo post è stato scritto con l’assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.
Fonti
Paolo Benanti, “I costi del software: far emergere ciò che il mercato non prezza”, rubrica Etica di frontiera, Il Sole 24 Ore, 12 agosto 2026
Ward Cunningham, “The WyCash Portfolio Management System”, OOPSLA ’92 Experience Report, 1992, e “Debt Metaphor”, video, 2009
Martin Fowler, “Technical Debt Quadrant”, martinfowler.com, 14 ottobre 2009
Meir M. Lehman, “Programs, Life Cycles, and Laws of Software Evolution”, Proceedings of the IEEE, 68(9), 1980, pp. 1060-1076
E. Burton Swanson, “The Dimensions of Maintenance”, Proceedings of the 2nd International Conference on Software Engineering, 1976, pp. 492-497
Bennet P. Lientz, E. Burton Swanson, Software Maintenance Management. A Study of the Maintenance of Computer Application Software in 487 Data Processing Organizations, Addison-Wesley, 1980 (dati citati nella lettura che ne danno Keith H. Bennett e Václav Rajlich, “Software Maintenance and Evolution: a Roadmap”, ICSE 2000 — The Future of Software Engineering)
Barry W. Boehm, “A Spiral Model of Software Development and Enhancement”, ACM SIGSOFT Software Engineering Notes, 11(4), agosto 1986, pp. 14-24
Rebecca Fox, “Technical debt is the tax killing AI ambition”, CIO, 6 marzo 2026
Peter M. Senge, The Fifth Discipline. The Art and Practice of the Learning Organization, Doubleday, 1990 (ed. it. La quinta disciplina. L’arte e la pratica dell’apprendimento organizzativo, Sperling & Kupfer, 1992)
ISO/IEC/IEEE 14764:2022, “Software engineering — Software life cycle processes — Maintenance”, ISO, gennaio 2022
“Direttiva (UE) 2024/2853 sulla responsabilità per danno da prodotti difettosi”, Parlamento europeo e Consiglio, 23 ottobre 2024, che abroga la direttiva 85/374/CEE (recepimento entro il 9 dicembre 2026)
“Regolamento (UE) 2024/2847 relativo a requisiti orizzontali di cibersicurezza per i prodotti con elementi digitali” (regolamento sulla ciberresilienza), Parlamento europeo e Consiglio, 23 ottobre 2024, Allegato I
McKinsey, “The cost of intelligence: How CIOs can manage AI demand at scale”, McKinsey Quarterly, 20 luglio 2026 (dati dalla Enterprise AI FinOps survey, maggio 2026)
Alfonso Fuggetta, “Usare l’AI per costruire software o costruire software di AI?”, A bassa voce, 14 agosto 2026
© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it
“I’m never in favor of writing code poorly but I am in favor of writing code to reflect your current understanding of a problem even if that understanding is partial” (trascrizione del parlato, traduzione mia nel testo).
McKinsey, Enterprise AI FinOps survey, maggio 2026: 120 partecipanti, 75 rispondenti qualificati in cinque settori. Va letta per ciò che è, un’indagine di una società di consulenza sul proprio campione, non una rilevazione statistica; l’ordine di grandezza, però, è coerente con quanto si sente dalle aziende.
Lehman formula le prime tre leggi nel 1974 e ne pubblica cinque nella versione del 1980. Avvertiva che non si tratta di leggi immutabili come quelle della fisica: nascono da abitudini e pratiche di persone e organizzazioni, e cambiano con esse.