Perché il codice perfetto non deve esistere

Il problema dei codici è la loro qualità. Questo non significa che si riparano autonomamente o risolvono i propri problemi nel modo migliore e più efficiente, o che è garantito che raggiungano la perfezione modulare. È solo che i codici durano. Il principio guida dell'ingegneria informatica è la compatibilità e, nella programmazione, questa si traduce praticamente in riutilizzabilità. Codici di qualità o semplicemente ben funzionanti non hanno bisogno di essere riscritti.

Il logico risultato è quello che Nicholas Cass di Rough Type definisce un "peak code", un codice definitivo in poche parole. Viene descritto in un paper elaborato da tre economisti della Boston University che lavorano con Jeffrey Sachs, fondatore dell'Earth Institute, e che ha modellato un futuro teorico in cui i programmatori sono diventati inutili poiché sono diventati troppo bravi nel programmare. Il codice migliore scritto dal miglior programmatore non ha bisogno di essere riscritto, per questo deve essere eliminato dal mercato, assieme al suo programmatore.

"La nostra economia simulata è un computer modello ​barebone," scrivono Sachs et al. "Considera due tipi di lavoratori che consumano due beni per due periodi. E ammette un'ampia gamma di risultati dinamici, alcuni dei quali sono molto spiacevoli." Questo è il risultato dell'"accumulo dei codici", in cui i programmatori del passato finiscono a competere con i programmatori attuali e con quelli futuri. È abbastanza semplice immaginarli come un'unico gruppo di persone.

Il risultato, spiegano gli economisti, è il crollo che avverrebbe a un certo punto in un futuro non così distante. "La combinazione di codici e capitale che produce merce costituisce, in effetti, macchinari intelligenti, ovvero robot," scrivono Sachs e il suo team. "E questi robot hanno le qualità umane, capacità cerebrali cumulative e conservano energia. Prendete Junior ad esempio, il computer campione del mondo di scacchi. Junior può battere qualsiasi attuale e probabilmente futuro essere umano sul pianeta. Il suo vecchio codice ha fatto fuori qualsiasi possibilità di business per programmatori di scacchi."

Come spiegano gli autori, il peggioramento è inversamente proporzionale alla proprietà dei software, quindi l'open-source, ad esempio, è parte del problema. È una considerazione piuttosto cinica, ma c'è del vero.

Detto ciò, però, la confutazione è interna allo stesso esempio degli scacchi di Sachs. Il gioco rimane lo stesso, le regole anche. Programmare bot che giocano a scacchi è una situazione idealizzata, in cui i software si troverebbero ad esistere in un contesto statico. Una partita a scacchi sarà una partita a scacchi anche domani o tra cento anni.

Tuttavia i codici del mondo reale è raro trovarli in contesti statici. Ed è per questo che esiste la software rot (letteralmente "decadimento dei software"). Gli ambienti in cui operano i codici sono dinamici e lo saranno sempre. Il risultato di ciò è quindi un declino: i codici diventano sempre meno adatti per le situazioni che si presentano man mano, sviluppano bug e profonde inefficienze.

Il decadimento avanza e i software statici diventano inclini agli errori, e si avviano inevitabilmente verso l'obsolescenza . Non possiamo programmare ogni scenario futuro. In un mondo ideale potremmo estendere l'argomento di Sachs a qualsiasi cosa: ponti, ricette, arte, architettura. Quindi cosa si dovrebbe dire ad esempio dell'architettura o dell'ingegneria civile? Dovrebbe esiste questo tipo di angoscia anche in quegli ambiti? Che cosa accadrebbe se facessi questo ponte troppo bene?

C'è qualcosa nei codici che li rende diversi da tutte le altre cose che sono creazione dell'uomo? Se sì, questo diventa un problema solo in un mondo immutabile. La logica matematica è sicuramente più resiliente del cemento e dei canoni estetici, ma la resilienza è operativa soltanto in un mondo dinamico. Il terreno si muove e il cemento si rompe. E lo stesso accade con i software.