Cruft, non patina

Stewart Brand, trentadue anni fa, ha pubblicato un libro che si chiama How Buildings Learn. L’idea di fondo è semplice e scomoda: un edificio ben progettato non è quello che resta identico a sé stesso, ma quello che sa essere modificato, abitato, rattoppato, reinterpretato nel tempo. Brand fotografa gli stessi edifici a distanza di decenni e mostra le alterazioni che ne raccontano la storia. Una scala aggiunta su un lato, un tramezzo abbattuto per unire due uffici, un tetto rifatto dopo l’incendio, una facciata dipinta tre volte e poi lasciata scrostare. La qualità architettonica, sostiene Brand, non si misura nel momento dell’inaugurazione ma in come l’oggetto regge all’uso umano stratificato. La parola che usa per questa condizione è learning: gli edifici imparano, nel senso che il loro tessuto fisico accumula informazione attraverso gli anni, e a un certo punto la quantità di informazione accumulata diventa essa stessa parte del valore dell’oggetto.

Il software non impara, in questo senso. Il software accumula commenti che si scusano.

L’archeologia del codice vecchio

Chiunque abbia lavorato su una codebase vecchia più di dieci anni riconosce un certo tipo di commento. // HACK: rimuovere quando migreremo all'API v2. // TODO: capire perché questo funziona. // NON TOCCARE: ha rotto la produzione tre volte. Sono firme di persone che non lavorano più lì, destinate a lettori futuri che non arriveranno mai davvero a risolverle. Sono patina? Sono tessuto cicatriziale, piuttosto. La differenza non è soltanto lessicale. Una sedia di Alvar Aalto del 1932, se è stata usata davvero, oggi ha un valore estetico che la sedia uscita dalla fabbrica nel ‘32 non aveva. Il legno si è scurito nei punti dove le mani si appoggiano. La finitura opaca ha perso lucentezza in modo non uniforme, ha imparato il corpo di chi ci si è seduto. C’è forse una riparazione nel punto di giunzione tra gamba e seduta, una vite cambiata, un rinforzo fatto con gusto da qualche proprietario intermedio. Tutto questo non la rende peggiore. La rende più bella, più preziosa, più sé stessa. Un restauratore serio rifiuta di rimuovere la patina, perché la patina è diventata parte costitutiva dell’oggetto. Il restauro è l’arte di distinguere il danno dalla storia.

Un software PHP del 1998, se è stato usato davvero, oggi non ha nessun valore estetico aggiunto. Ha workaround stratificati per browser che non esistono più. Ha controlli di validazione che sono stati aggiunti tre volte a tre livelli diversi perché a ogni ciclo di manutenzione nessuno si fidava di quelli preesistenti. Ha funzioni di quattrocento righe che gestiscono casi particolari introdotti da clienti che non sono più clienti da dieci anni. Nessuno propone di preservare questa condizione come parte del valore del prodotto. Si parla di debito tecnico, termine rivelatore: debito, non storia. Qualcosa da estinguere, non da onorare. Il vocabolario stesso con cui il settore descrive il proprio rapporto con il tempo rivela che non c’è nessun concetto disponibile per chiamare bello un sistema vecchio. Al massimo si può dire che è “solido”, “battle-tested”, “proven”. Sono virtù di resistenza, non virtù di accumulazione.

L’archeologia del codice vecchio è una disciplina informale che ogni sviluppatore senior pratica senza averla mai studiata, e che ha le sue costanti riconoscibili. Ci sono gli strati di compatibilità con browser ormai estinti: if (window.ActiveXObject) per riconoscere le vecchie versioni di Internet Explorer, hack CSS che sfruttano bug specifici di Firefox di prima delle grandi rewrite, condizioni che controllano la presenza di window.attachEvent per distinguere IE dal resto dei browser quando i browser concorrenti erano molti e tutti diversi. Ci sono feature flag accesi per rollout graduali mai completati, dove metà del codice è dietro una condizione if (feature_active('new_checkout_flow')) e l’altra metà nel ramo else, e la feature è in produzione al cento per cento da sette anni ma nessuno ha il coraggio di rimuovere il ramo morto perché nessuno ricorda esattamente cosa facesse. Ci sono migrazioni di schema iniziate e mai portate a termine, in cui due colonne coesistono nella stessa tabella, una con il nome vecchio e una con il nome nuovo, scritte entrambe dalla logica applicativa “per sicurezza”, lette selettivamente a seconda del punto del codice in cui ci si trova. Ci sono funzioni con nomi come processOrderLegacy, processOrderLegacyV2, processOrderFinal, processOrderActuallyFinal, che testimoniano una progressione di tentativi di pulizia nessuno dei quali è stato davvero completato. Nulla di questo è patina. È un registro sedimentario di promesse non mantenute, di intenzioni che la vita aziendale ha sistematicamente superato prima che si realizzassero. Se un restauratore di mobili trovasse in un cassettone del Settecento venti strati sovrapposti di vernice, ognuno steso senza rimuovere il precedente, non direbbe che l’oggetto ha guadagnato valore attraverso le stratificazioni: direbbe che è stato trattato male, e proporrebbe un intervento di rimozione. Il codice vecchio è trattato esattamente così anche dagli addetti ai lavori, che lo chiamano legacy con un tono in cui la neutralità tecnica si mescola con un velato disprezzo. La parola stessa è forse la spia più esplicita del rapporto irrisolto del settore con il proprio passato: viene dal latino legare, lasciare in eredità, ma nell’uso tecnico ha preso un significato quasi opposto, cioè qualcosa che è stato subìto e di cui ci si vorrebbe liberare. Il lascito come fardello, non come dono.

Perché il software non invecchia

La domanda è perché. Perché gli oggetti materiali riescono a guadagnare in qualcosa attraverso il tempo, mentre gli oggetti digitali sembrano poter solo perdere. Una risposta facile è che si tratta di una differenza ontologica: il codice è pura semantica, non ha un substrato materiale su cui possano depositarsi i segni dell’uso. Il legno respira, assorbe umidità, si ossida, si consuma nei punti di attrito. Il byte non fa niente di tutto questo. Un file binario oggi è bit-per-bit identico a quando è stato scritto, salvo corruzioni accidentali del supporto, e anche queste corruzioni non hanno nessun valore semantico: non dicono nulla dell’uso che se ne è fatto. La risposta facile ha il difetto di tutte le risposte facili, che è quello di chiudere il discorso proprio nel punto in cui dovrebbe cominciare.

Proviamo ad andare un po’ più a fondo. Il motivo per cui una sedia invecchia bene non è che sia fatta di legno, ma che il suo intorno resta sostanzialmente stabile. La gravità non cambia. La fisiologia umana non cambia. La funzione di “sostenere un corpo seduto” non cambia. Le modifiche che la sedia subisce sono modifiche interne al suo tessuto, in dialogo con un ambiente che si muove molto più lentamente di lei. La sedia e il mondo attorno alla sedia invecchiano insieme, e invecchiano alla stessa velocità, e il risultato è una specie di co-evoluzione addomesticata. Il software esiste in un ambiente che si muove molto più velocemente di lui. Il browser cambia versione ogni quattro settimane. Il linguaggio rompe la retrocompatibilità ogni due anni. Le librerie hanno un ciclo di vita più corto di un mandato parlamentare. Il sistema operativo sotto cui gira smette di esistere nella forma in cui era stato compilato. Il software non invecchia internamente, come fa il legno. Si stacca progressivamente dal suo ambiente, come un’astronave che ha finito il propellente e vede la stazione spaziale allontanarsi. Quello che chiamiamo “software aging” non è aging nel senso della sedia. È drift ambientale. È la misura della distanza crescente tra un artefatto fisso e un contesto che si muove.

Questa differenza è ontologicamente rilevante. Un edificio e il suo contesto urbano invecchiano insieme in dialogo continuo, e questa co-appartenenza è la condizione stessa del fatto che si possa parlare di “invecchiamento” in senso proprio. Il software non ha co-appartenenza: ha compatibilità, che è una relazione molto più povera. Compatibilità significa solo che due cose che non si parlano possono continuare a far finta di parlarsi per un altro ciclo di rilascio. Quando Stewart Brand scrive che gli edifici imparano, sta descrivendo un processo in cui l’edificio e i suoi abitanti si modificano a vicenda. Quando un sistemista aggiunge un compatibility shim per far girare un vecchio eseguibile sul nuovo kernel, sta mettendo un cuneo tra due mondi che non si parlano più, e sta comprando tempo. Lo shim è l’opposto dell’apprendimento: è l’ammissione che l’apprendimento non è possibile, che si può solo simulare la comunicazione.

Ruskin, e la verità dell’uso

C’è un passaggio in Ruskin, nelle Seven Lamps of Architecture, in cui sostiene che un edificio nuovo è per sua natura falso, e diventa vero solo attraverso la frequentazione degli anni. Ruskin è vittoriano, enfatico, spesso irritante, ma questa frase è una delle cose più precise che siano state dette sull’oggetto costruito. La verità di un edificio non è nel progetto ma nella storia del suo uso. Se applichiamo lo stesso criterio al software, bisogna concludere che il software non diventa mai vero. Resta in uno stato permanente di novità, anche quando la sua data di compilazione è di venticinque anni fa, perché l’accumulazione di storia che dovrebbe renderlo reale in senso ruskiniano non è possibile nel suo mezzo. L’unica cosa che accumula è l’incompatibilità crescente con il suo intorno, e questo non è storia: è erosione.

L’obiezione Unix

A questo punto bisogna affrontare l’obiezione forte, quella che ogni lettore tecnicamente competente ha già formulato mentalmente nei primi paragrafi, e che se non viene affrontata rende tutto il ragionamento precedente sospetto. L’obiezione è: ma Unix è vecchio di più di mezzo secolo, e non solo funziona ancora, ma è diventato più elegante nel tempo, non meno. POSIX, TCP/IP, SQL, il filesystem gerarchico, la pipe. Sono tutte idee che hanno fra i quarant’anni e il mezzo secolo abbondante sulle spalle. Sono ancora al centro dell’infrastruttura digitale del pianeta. Non si comportano come il PHP del 1998 di prima. Si comportano, se vogliamo, esattamente come la sedia di Aalto: oggetti che hanno attraversato il tempo guadagnando, non perdendo. Qualcosa nel ragionamento non torna.

L’obiezione è seria e merita una risposta seria. La risposta più facile sarebbe dire che Unix è un’eccezione, un outlier, un caso fortunato che non invalida la regola. Sarebbe una risposta povera. La risposta più interessante è che Unix non contraddice il ragionamento precedente, ma ne mostra il meccanismo esatto, e chiarisce una distinzione che finora è rimasta implicita. La distinzione è tra software come codice e software come specifica.

Specifica, non codice

Quello che chiamiamo “Unix” oggi non è, letteralmente, il software che Ken Thompson e Dennis Ritchie hanno scritto ai Bell Labs tra il 1969 e il 1971. Quel codice è morto da decenni. Il ramo commerciale AT&T è stato venduto, smembrato, riassorbito. BSD è stato forkato molte volte, e ciascun fork è stato a sua volta riscritto. Linux, che è oggi la forma dominante di “Unix” nell’infrastruttura globale, non condivide una singola riga di codice con il Unix originario: è una reimplementazione indipendente, avviata da Linus Torvalds nel 1991, che espone le stesse interfacce di sistema (chiamate, struttura del filesystem, convenzioni) ma è stata scritta da capo. macOS deriva da NeXTSTEP, che a sua volta poggia sul microkernel Mach e su componenti BSD, e anche qui il codice è stato riscritto e rifuso tante volte che la continuità materiale con il punto di partenza è puramente rituale. Quello che è sopravvissuto non è il corpo di Unix, ma la sua forma. La sua interfaccia. La sua grammatica. Il fatto che ci siano chiamate di sistema che si chiamano open, read, write, close, e che funzionino più o meno come funzionavano nel 1973, non vuol dire che il codice che le implementa sia invecchiato bene. Vuol dire che la specifica che le definisce è diventata una cosa diversa dal codice: è diventata cultura, convenzione, linguaggio condiviso, norma de facto e poi norma de iure tramite POSIX.

Lo stesso vale per TCP/IP. Il protocollo è sopravvissuto, l’implementazione no, o almeno non nella sua forma originaria. Ogni stack TCP/IP moderno, da Linux a Windows a iOS all’ESP32 che alimenta una lampadina intelligente, è stato riscritto o riallineato più volte nei decenni. La 4.4BSD networking code, che per lungo tempo ha fornito la base di riferimento del kernel di rete in molti sistemi, è stata via via assorbita, ramificata e reimplementata al punto che i codici moderni mantengono con essa una parentela storica più che materiale. Quello che persiste, immutato, è l’RFC: un documento di testo che descrive, in inglese tecnico, come due macchine dovrebbero parlarsi. L’RFC non è software. È più simile a un trattato diplomatico che a un programma. È per questo che invecchia bene: perché appartiene alla stessa classe di oggetti di un trattato diplomatico, o di una costituzione, o di una grammatica. È una convenzione condivisa la cui forza non sta nella sua implementazione ma nel numero di attori che la riconoscono come vincolante.

SQL è il caso più istruttivo. La sintassi SELECT ... FROM ... WHERE è stata definita a metà degli anni Settanta da Donald Chamberlin e Raymond Boyce alla IBM. Oggi la usa chiunque. Ma nessun database relazionale oggi in produzione gira sul codice originale di System R. Postgres è una reimplementazione. MySQL è una reimplementazione. SQLite è stato scritto da zero negli anni Duemila e oggi è probabilmente il database più diffuso al mondo per numero di istanze attive, superato forse solo dai fogli Excel. Il codice che implementa SQL è morto e rinato tante volte che non ha senso parlare di continuità materiale. Quello che è rimasto è il modello relazionale, che è un oggetto matematico, e una certa sintassi, che è un oggetto culturale. Entrambi si sono staccati dal codice che li aveva inizialmente incarnati, e proprio per questo hanno potuto attraversare il tempo.

TeX, SQLite, e le eccezioni che confermano

Ci sono però alcuni casi, rarissimi, in cui il codice stesso sembra essere riuscito in qualcosa che assomiglia davvero alla patina, e vale la pena osservarli perché illuminano per contrasto la condizione generale. TeX, il sistema di composizione tipografica scritto da Donald Knuth a partire dal 1978, è uno di questi. Knuth ha deciso a un certo punto che TeX fosse finito, nel senso letterale del termine: nessuna nuova feature, soltanto correzioni di bug, e il numero di versione che converge asintoticamente verso il valore di pi greco a ogni release, con l’intento esplicito che l’ultima versione, quando Knuth morirà, assuma il valore esatto di pi greco e che il software smetta di cambiare per sempre. Knuth offre una piccola ricompensa monetaria, che raddoppia ogni anno, a chiunque trovi un bug in TeX, e ormai da molti anni nessuno li reclama. Non perché non ci siano, ma perché il software è stato usato così tanto e per così tanto tempo che i bug residui vivono in angoli che non vengono mai visitati. TeX funziona oggi come funzionava a fine anni Ottanta, compila gli stessi file sorgente, produce lo stesso output tipografico. Il suo codice, scritto in WEB (un sistema di literate programming inventato da Knuth stesso, che combina Pascal per la logica di programma e TeX per la documentazione), è stato pubblicato nel 1986 con il titolo TeX: The Program, come Volume B di Computers and Typesetting, ed è trattato come un’opera letteraria. È stato letto, commentato, studiato. È una delle poche volte in cui il codice ha oltrepassato la soglia dell’implementazione pura ed è diventato esso stesso qualcosa di simile a una specifica, ma nella forma concreta del programma, non nella forma astratta del documento RFC. Knuth ha ottenuto questo risultato imponendo alla propria opera una condizione estrema: rifiutare ogni evoluzione. TeX non invecchia perché ha scelto di non vivere, in un certo senso. Ha accettato la mummificazione come prezzo della permanenza.

SQLite è l’altro caso interessante, più recente e meno mistico. I suoi sviluppatori hanno dichiarato pubblicamente, nella documentazione del progetto, l’intenzione di mantenere la libreria almeno fino al 2050, con piena retrocompatibilità dell’API C e del formato on-disk. Questo impegno non è una formula di stile ma un vincolo concreto che deriva dal fatto che SQLite è integrato in sistemi avionici (Airbus A350 tra gli altri), dispositivi medicali, apparati militari, tutti oggetti con cicli di vita che superano i quarant’anni. Per sostenere un simile orizzonte, SQLite ha costruito un apparato di test che, secondo le cifre dichiarate dagli stessi sviluppatori, arriva a circa novantadue milioni di righe di codice di test contro le centocinquantamila righe della libreria vera e propria, un rapporto di quasi seicento a uno. Ogni diramazione condizionale del codice è coperta da test MC/DC, lo standard impiegato nell’avionica per le certificazioni DO-178B. Il codice stesso è scritto con attenzione esplicita al fatto che sarà letto e mantenuto da persone non ancora nate. SQLite ha preso il problema della durata come problema di design fin dall’inizio, e ha trattato la stabilità della propria interfaccia come una questione etica più che tecnica. Il risultato è un pezzo di software che esiste da più di venticinque anni, gira su miliardi di dispositivi, e che nessuno ha mai sentito il bisogno di riscrivere da capo. È un caso in cui il codice stesso, non la sua specifica, sembra essere invecchiato bene. Ma se si guarda più da vicino, si capisce che questo risultato è stato ottenuto solo al prezzo di un’accettazione radicale di vincoli che il resto del settore non sarebbe disposto ad accettare. SQLite non cambia quasi mai, anche a costo di rinunciare a feature che renderebbero il codice più moderno. SQLite non ha dipendenze esterne, quasi una protesta contro il modo in cui il resto del mondo costruisce software oggi. SQLite ha una cultura interna disciplinare che rasenta il monastico. In altre parole, SQLite riesce a invecchiare bene perché si è costruito una nicchia ecologica in cui l’ambiente attorno al codice è stato artificialmente stabilizzato. Ha ricreato, dentro un piccolo perimetro, le condizioni che permettono alla sedia di Aalto di diventare più bella con gli anni: un ambiente che si muove lentamente, un utilizzatore attento, una cultura che riconosce il valore della durata. Non è un caso che questi esempi siano, statisticamente, delle anomalie. Sono le eccezioni che rivelano esattamente quali sono le condizioni necessarie per l’invecchiamento del software, e confermano che queste condizioni, nel corpo principale del settore, non esistono.

Il corpo muore, la specifica risorge

Se guardiamo la questione da questo angolo, Unix non invecchia bene. Unix è continuamente risorto. Il corpo muore e viene rifatto da zero, a partire da una specifica che nel frattempo è diventata sacra al punto da meritare la riscrittura integrale del corpo ogni venti o trent’anni. È la struttura di una religione più che di un oggetto materiale. La sedia di Aalto, per rimanere sulla nostra metafora, non è mai stata rifatta da zero: la sedia di Aalto del 1932 è fisicamente lì, con le sue ammaccature. Se applicassimo al legno la logica di Unix, dovremmo dire che il concetto di “sedia Paimio modello 41” è sopravvissuto perché Artek, dalla sua fondazione nel 1935, ne ha continuato la produzione per oltre novant’anni, e che le sedie del 2026 sono discendenti di quelle del 1932 ma non sono le stesse sedie. Sarebbe vero, ma spostato: quello che ci interessa della sedia del 1932 è proprio la sua durata materiale, non la persistenza del suo modello. Nel software accade l’opposto. Non ci interessa il codice originario, e nessuno lo conserva come reliquia. Ci interessa la persistenza del modello, e questa persistenza richiede la distruzione e riscrittura periodica del codice.

L’obiezione Unix, quindi, non smentisce il ragionamento ma lo ridefinisce. Quello che invecchia bene nel digitale non è codice. Sono specifiche che hanno avuto la fortuna, e il capitale culturale, di sollevarsi al di sopra del loro substrato di implementazione e diventare qualcosa di diverso. Norme. Interfacce stabili. Lingue franche. La maggior parte del codice non raggiunge mai questo livello e non può raggiungerlo. Il 99% del software che gira oggi nel mondo non diventerà POSIX. Il CRM su misura di un’azienda di quattrocento dipendenti non diventerà SQL. Il sito e-commerce di una catena di negozi non diventerà TCP/IP. Non perché sia scritto male, ma perché non è quel tipo di oggetto. È, strutturalmente, implementazione. E l’implementazione, nel digitale, non può invecchiare bene, perché non ha nessuno dei requisiti per farlo: non ha substrato materiale che registri l’uso, non ha ambiente stabile in cui permanere, non ha il peso culturale che permette la reincarnazione periodica.

Riscrivere non è un peccato

Questa distinzione illumina anche un dibattito interno al settore che è sempre stato mal posto. Joel Spolsky, nel 2000, scrisse un articolo che ha avuto molta fortuna, intitolato Things You Should Never Do, Part I, in cui sosteneva che riscrivere da zero un software funzionante è il peggiore errore strategico che un’azienda di software possa commettere. L’argomento era buono e specifico: Netscape aveva perso il mercato perché si era messa a riscrivere il browser da zero, lasciando finestra aperta a Internet Explorer per tre anni. Il problema dell’articolo di Spolsky è che generalizza da un caso particolare senza riconoscere che la maggior parte del software deve essere riscritta, prima o poi, perché non può essere mantenuta indefinitamente nella forma in cui è stata concepita. Unix è stato riscritto più volte. Linux stesso, a livello di singoli sottosistemi, viene continuamente riscritto: lo scheduler è stato sostituito, il networking stack è stato rifatto, il filesystem è stato ripensato. Quello che Spolsky chiamava “non riscrivere mai” è in realtà “non perdere la continuità della specifica durante la riscrittura”, che è una cosa molto diversa e molto più difficile. La riscrittura fallisce quando perde il contatto con quello che il codice doveva fare per i suoi utenti reali. Riesce quando conserva la specifica e butta via l’implementazione, nello stesso modo in cui il corpo di un cattolico viene sepolto ma l’anima migra altrove.

Una dignità preclusa

Se questa lettura è corretta, allora la tristezza sottesa a buona parte del lavoro tecnico quotidiano ha una spiegazione strutturale e non psicologica. Non stiamo scrivendo male. Stiamo scrivendo oggetti che non possono invecchiare, perché non apparteniamo alla classe ristretta degli artefatti che possono elevarsi a specifica culturale. Il 99% di quello che scriviamo è destinato a morire senza lasciare traccia, non per un difetto di fattura ma per una proprietà del mezzo. Un muratore del Duecento sapeva che se il suo muro era fatto bene sarebbe stato lì nel Cinquecento, e probabilmente anche oltre. Un idraulico del Novecento sapeva che i suoi tubi, con un po’ di manutenzione, avrebbero servito tre generazioni. Uno sviluppatore del 2026 sa che il codice che sta scrivendo oggi, con buone probabilità, sarà dismesso entro cinque o sette anni. Non perché sia stato scritto peggio dei tubi. Ma perché il tubo e il muro appartengono a un regime in cui l’invecchiamento è possibile, e il codice no.

Questo cambia la natura etica del mestiere in modi che non abbiamo ancora metabolizzato. Costruire qualcosa di duraturo è stato per millenni una delle forme più alte di dignità del lavoro umano. La cattedrale, il ponte, il libro stampato, il violino. Oggetti fatti con la coscienza di durare oltre la vita di chi li costruiva. Lo sviluppo software è uno dei pochi mestieri ad alta qualifica in cui questa dignità è strutturalmente preclusa. Non perché nessuno lavori bene, ma perché il mezzo non ammette quel tipo di durata. Il debito tecnico di cui parlavamo all’inizio, visto da questa angolatura, non è un difetto gestibile con migliori pratiche, maggiore disciplina, test più rigorosi, revisioni del codice più attente. È la forma specifica che assume l’inevitabile deterioramento di un artefatto che non ha altro modo di deteriorarsi. È il modo in cui il software invecchia male perché non sa invecchiare in nessun altro modo.

La lampada della memoria

C’è una lettura più ampia di tutto questo, che esce dal dominio strettamente tecnico e tocca qualcosa di più scomodo sulla cultura in cui viviamo. Ruskin, di nuovo, identificava sette virtù dell’architettura, che chiamava lampade. Sacrificio, verità, potenza, bellezza, vita, memoria, obbedienza. La lampada della memoria era, per lui, la virtù degli edifici che si lasciano attraversare dal tempo senza resistergli, che conservano le tracce di chi li ha abitati, che diventano a loro modo archivi biografici del passaggio umano. Una civiltà che non sa costruire oggetti capaci di memoria, diceva Ruskin, è una civiltà che ha rinunciato a una delle sue funzioni fondamentali, che è quella di tramandare sé stessa attraverso le sue cose.

Il digitale, da questo punto di vista, è l’opposto esatto dell’architettura ruskiniana. È una cultura materiale, se così si può ancora chiamare, in cui la memoria non si accumula nelle cose ma le lascia. Il software di cinque anni fa è già un’antichità. Il sito web di dieci anni fa non è più accessibile, il suo dominio è scaduto, i suoi link sono tutti rotti, le sue immagini puntano a server dismessi. Gli archivi digitali esistono solo grazie a sforzi eroici e marginali: Internet Archive è un singolo punto di fallimento per la memoria di tre decenni di cultura online, e nessuno ha capito davvero come sostituirlo. Le nostre fotografie sono su server che non possediamo, in formati che potrebbero non essere letti tra vent’anni, protette da contratti di servizio che possono essere modificati unilateralmente. La nostra corrispondenza è in caselle di posta che spariranno quando l’azienda che le ospita deciderà di cambiare modello di business. La continuità materiale del patrimonio umano, che per millenni è stata garantita, sia pure imperfettamente, dalla durata fisica degli oggetti, è diventata precaria in un modo che nessuna civiltà precedente aveva conosciuto.

Questa precarietà non è un effetto collaterale ma una proprietà strutturale del mezzo. E il software, che è il cuore di questa nuova condizione, eredita e amplifica la precarietà. Non invecchia perché non sa accumulare memoria nelle sue fibre. Non ha fibre. La sua unica forma di continuità è la riscrittura, che è il contrario esatto della memoria: è la produzione periodica di un nuovo oggetto che finge di essere lo stesso.

Qualcuno a questo punto potrebbe obiettare che sto drammatizzando, che ogni epoca ha avuto la sua precarietà, che il papiro si decomponeva e la pergamena veniva raschiata per riusarla e il libro stampato brucia. È vero, ma la differenza quantitativa è tale da diventare qualitativa. La durata media di un libro stampato ben conservato si misura in secoli. La durata media di un file digitale si misura in anni, forse decenni nei casi fortunati. Il delta è di uno o due ordini di grandezza. Una civiltà in cui gli oggetti culturali durano cento volte meno rispetto alla precedente è una civiltà strutturalmente diversa, non solo quantitativamente ma qualitativamente. Ha un altro rapporto con il tempo. Produce un’altra soggettività in chi la abita. Uno sviluppatore sa, in un modo che un tipografo del Cinquecento non sapeva, che il suo lavoro non lo sopravvivrà.

L’obiezione dell’effimero

C’è un modo di leggere tutto questo che è meno tragico, e vale la pena attraversarlo prima di chiudere. L’obiezione possibile è che la permanenza non sia necessariamente una virtù, e che il software potrebbe rappresentare una forma di produzione culturale deliberatamente effimera, nel senso in cui una performance teatrale o un concerto jazz sono effimeri, e che la loro effimerità non è un difetto ma una caratteristica costitutiva del loro modo di essere al mondo. Una funzione lambda che gira per trentasette millisecondi e poi sparisce non è un oggetto fallito perché non dura: è un oggetto pienamente realizzato perché ha fatto esattamente quello che doveva fare nel tempo giusto. La metafora del monumento, ereditata dall’architettura, potrebbe essere semplicemente inadatta al mezzo, e insistere sul fatto che il software “non invecchia bene” potrebbe essere come lamentarsi del fatto che un temporale non invecchia bene: confondere una categoria che non si applica.

L’obiezione è interessante ma si rompe nel momento in cui la si prende sul serio. Il problema non è il codice che gira per trentasette millisecondi. Quello è davvero un evento, non un oggetto. Il problema è che la quasi totalità del software di cui dipendiamo nella vita quotidiana non è un evento in questo senso: è infrastruttura. Il sistema con cui la nostra banca gestisce i conti non è una performance jazz. Il software medicale che controlla il ventilatore in terapia intensiva non è un temporale. Il database anagrafico del comune non è una funzione effimera. Sono oggetti che pretendono di essere infrastruttura, che noi trattiamo come infrastruttura, che le istituzioni iscrivono nei loro processi come se fossero infrastruttura, e che però hanno le proprietà di durata e memoria di una nuvola. Questa discrepanza tra la funzione sociale che il software svolge e le sue proprietà materiali di durata è il punto in cui la questione smette di essere filosofica e diventa civile. Una società che affida le sue funzioni vitali a oggetti che non sanno invecchiare sta, silenziosamente, trasferendo il costo della manutenzione della propria continuità a uno strato tecnico che non sa sostenerla.

Infrastruttura precaria, diritto che rincorre

Il Cyber Resilience Act europeo, adottato come Regulation (EU) 2024/2847 e in piena applicazione a partire dal dicembre 2027, la nuova Product Liability Directive (EU) 2024/2853, le obbligazioni previste dalla NIS2, sono, visti da questa angolazione, tentativi maldestri ma indicativi di forzare il software a comportarsi come infrastruttura seria. Obbligano i produttori a definire un periodo di supporto che rifletta il ciclo di vita atteso del prodotto, con un minimo di cinque anni nella maggior parte dei casi, a mantenere SBOM aggiornati, a rispondere delle vulnerabilità introdotte nel prodotto anche dopo la vendita. Sono, in un certo senso, il tentativo legislativo di imporre all’oggetto software le proprietà di durata che non ha per natura. Il fatto che queste regole esistano, e che siano percepite dal settore come un costo aggiuntivo invece che come un riconoscimento di responsabilità civile, dice qualcosa sul fatto che chi produce software ha internalizzato l’effimerità come privilegio. Il muratore sa di dover rispondere del suo muro per molti anni. Lo sviluppatore è abituato a rispondere del suo codice fino alla fine della garanzia contrattuale, che tipicamente è di dodici o ventiquattro mesi. Le due figure professionali hanno orizzonti temporali di responsabilità che differiscono di un ordine di grandezza, e questa differenza è invisibile nel linguaggio con cui le descriviamo.

Un’etica della durata

Tornando alla domanda iniziale, al perché il software non sa invecchiare, possiamo adesso dare una risposta meno lapidaria. Non sa invecchiare perché è fatto di un materiale che non ha grana, in un ambiente che si muove più velocemente di lui, dentro una cultura produttiva che ha rinunciato a considerare la durata come una delle dimensioni del valore. Ciascuno di questi tre fattori è causa sufficiente del risultato, e sommati rendono il risultato quasi inevitabile. Il primo è ontologico e probabilmente irrisolvibile: il codice non diventerà mai legno. Il secondo è sistemico e potrebbe essere attenuato, se la cultura tecnica imparasse a trattare la stabilità come un pregio invece che come un segno di arretratezza. Il terzo è puramente culturale ed è l’unico su cui si può davvero agire.

Agire come? Probabilmente in direzioni che il settore oggi considera regressive. Rallentando i cicli di rilascio. Preferendo la retrocompatibilità all’eleganza. Scrivendo meno codice e più specifica. Trattando le interfacce stabili come monumenti, cioè come oggetti il cui valore sta nella loro resistenza al cambiamento. Accettando che la maggior parte del codice non debba diventare Unix, e che proprio per questo debba essere scritto con una certa consapevolezza del suo destino di transitorietà, senza l’ambizione falsa della durata e senza la disperazione nichilista della sua assenza. Un mestiere che sa di non costruire cattedrali ma che rifiuta di costruire baracche. Una dignità intermedia, che non abbiamo ancora una parola buona per descrivere, e che è forse una delle cose che questa generazione di tecnici dovrebbe provare a formulare.

Se c’è una consolazione nel fatto che il software non invecchia bene, è che questa caratteristica ci obbliga a mettere a fuoco, per contrasto, cosa significhi invecchiare bene in generale. Ci costringe a riconoscere che la patina della sedia di Aalto non è un fatto automatico del legno, ma il risultato di una relazione lunga tra un oggetto ben fatto, un ambiente stabile, un utilizzatore attento e una cultura che sa riconoscere il valore di questa triangolazione. Quando uno di questi termini salta, la patina non si forma. Il legno lasciato sotto la pioggia non acquista patina, marcisce. Il legno tenuto chiuso in un deposito non acquista patina, si secca. La patina è un’opera collettiva che richiede tempo, cura e contesto. Il software, allo stato attuale, non ha nessuno di questi tre, e l’idea stessa che potrebbe averli suona come una fantasticheria nostalgica.

Non è una fantasticheria. È una domanda di progettazione. Cosa vorrebbe dire scrivere codice sapendo che deve durare quanto un muro? Non lo sappiamo ancora davvero, perché non ci siamo quasi mai provati con serietà, e quando ci abbiamo provato lo abbiamo fatto quasi sempre in ambiti marginali rispetto al mainstream: avionica, controllo industriale, sistemi bancari legacy, dove la durata è imposta dall’esterno come vincolo normativo più che scelta culturale. Il software civile, quello che costruisce la vita pubblica e privata della maggior parte delle persone, è stato costruito con l’assunzione implicita che la durata non sia un problema suo. Questa assunzione sta diventando insostenibile proprio mentre la società delega al software funzioni sempre più vitali. Tra le responsabilità di questa generazione di tecnici, probabilmente quella di cominciare a formulare un’etica della durata per il proprio mestiere è una delle più serie, e una delle meno rinviabili.

Rimane, alla fine, la questione di fondo. Il software non invecchia bene. Questa frase, all’inizio, sembrava una lamentela tecnica. Arrivati qui, si capisce che è qualcosa di diverso. È una descrizione esatta del tipo di artefatti che abbiamo deciso, collettivamente, di mettere al centro della nostra vita associata, e una richiesta implicita di fare i conti con quella decisione. Gli oggetti che mettiamo al centro di una civiltà dovrebbero, nei limiti del possibile, sapere accompagnarla nel tempo. Se non lo sanno fare, bisogna o cambiarli, o cambiare il posto che occupano. Finora abbiamo fatto né l’una né l’altra cosa. Abbiamo lasciato che occupassero il centro comportandosi come se fossero alla periferia, e abbiamo chiamato questa condizione “progresso”. Vale la pena cominciare a chiamarla con un nome più preciso.

L'autore

Andrea MargiovanniMestiere

Scrivo software da abbastanza tempo da considerarlo un mestiere, non una pipeline. Mi interessa la differenza fra una scelta tecnica e un default ereditato senza misurarne il costo.

Vai al percorso →