Questa è la seconda e ultima parte della presentazione dei motivi dietro alla realizzazione del mio romanzo "Il Grande Collasso", edito da Echos edizioni.
Nella prima parte di questa "analisi" delle ispirazioni che mi hanno portato a realizzare questa storia, si è parlato di libri.
I libri che mi hanno "donato qualcosa" sono stati vari e sarebbe inutile e noioso citarli ed analizzarli tutti, quindi mi limito a descriverne un altro soltanto, questa volta non un romanzo.
Sono costretto al limitarmi a dire "descrivere" perché il libro in questione non è più in mio possesso, forse restituito al legittimo proprietario.
Febbre persistente
A Marzo 2016 sono finito in ospedale per 12 giorni.
Non fu nulla di grave, per quanto "dodici giorni" non suoni molto bene.
Anche se stavo tutto sommato bene, il problema di essere ricoverato in una stanza di un piccolo ospedale così a lungo è fondamentalmente la noia (ovviamente, mi ritengo fortunato che il problema fosse solo annoiarsi).
I primi giorni (chiamiamola la prima fase) ero in posesso delle mie piene facoltà mentali e ho sfruttato la situazione per leggere parecchio. Leggere mi serviva anche a non pensare ai possibili problemi (per avere una diagnosi ci volle comunque qualche giorno).
C'è stata una fase intermedia dove leggere iniziava a stancarmi in fretta e sono passato alla fase di giocare col telefono o guardare serie in streaming. Visto da fuori sembravo un hikikomori.
Poi c'è stata l'ultima fase in cui avevo davvero iniziato a cedere e mi trovavo ad orari assurdi (prima delle 7 di mattina) a guardare su Youtube longplay di vecchi giochi del Commodore 64 o Amiga.
Di alcuni di questi avevo solo ricordi vaghi (come "Uomo dei boschi", che ho lì scoperto chiamarsi in realtà "Robin of the Wood" grazie al pazzo mondo della pirateria legalizzata in Italia di quegli anni).
Di altri era semplicemente la voglia nata dal nulla e completamente irrazionale di vederne la fine alla quale non ero mai arrivato (come Future Wars).
Ma torniamo un po' indietro.
Al termine della prima fase, mio fratello passò a trovarmi e mi portò un libro.
Non era una lettura leggera, non era un libro di narrativa ma un testo universitario di ingegneria del software.
Qualcuno potrebbe ipotizzare che lo abbia fatto per danneggiarmi o che sia responsabile dell'avvento della fase intermedia e del mio tracollo psicologico
ma queste sono dicerie, ovviamente non ne avrò mai le prove.
Rimane il fatto che iniziai a leggerlo (non lo finii, nemmeno dopo essere tornato a casa, forse perché lo associavo troppo a quel periodo non troppo bello). Da notare che al tempo ero già laureato in informatica e già lavoravo come sviluppatore da anni, ma in effetti era passato molto tempo dall'ultima lettura teorica sul software (per l'appunto: dalla fine dell'università).
Di quel libro non ricordo quasi nulla (neppure il titolo) ma aveva un buon incipit, che chi ha letto il mio racconto riconoscerà.
L'autore faceva un parallelo tra gli ingegneri del software e gli ingegneri di qualunque altra branca, riconoscendo come i progettisti di software fossero dispensati dall'infallibilità: il bug, il difetto in un software, è qualcosa che a noi è permesso.
La fallibilità del software
Se il progettista di una struttura qualunque (diciamo un architetto che costruisca un ponte) disegnasse qualcosa che finisse per crollare velocemente… beh, non la passerebbe liscia.
Qualcuno è vecchio abbastanza da ricordare i famigerati "test dell'alce" delle Mercedes Classe A a fine anni '90? Le risposte a quei problemi non sono certo state «Opperbacco, è "un bug"! OK, lo correggeremo» e poi tutti a pranzo.
Per il software è diverso, il software fallisce e nessuno può imporre il contrario. Il software può essere vulnerabile ad attacchi e l'unica soluzione è aggiornare la falla e riprovare.
Ovviamente il libro poi si spingeva verso le tecniche per mitigare queste problematiche (che esistono!) ma quelle poche parole mi rimasero impresse.
Ricordo che in quel momento mi tornò alla mente un episodio precedente: anni prima un mio responsabile aveva dichiarato che il software che io e i miei colleghi producevamo doveva essere "privo di errori", in caso contrario significava che non avevamo fatto un buon lavoro.
Sul che cosa questo significasse nella pratica per noi dipendenti non fu mai chiarito (penso fosse solo un modo per "spronarci"), ma io e i miei colleghi ci guardammo attoniti e ne parlammo parecchio.
Perché non è così che funziona. Non col software.
Per fare un esempio pratico tra le centinaia che potrei portarvi: anni fa scrissi una procedura che rimase in produzione mesi, poi iniziò a fallire misteriosamente. Per trovare l'origine di questo fallimento spesi ore. Iniziai a pensare alle ipotesi più diverse: la procedura non era stata toccata da nessuno, quindi trovavo logico partire dal presupposto che il problema fosse "altrove".
Sappiate che gli sviluppatori hanno sempre tante idee diverse quando devono dare la colpa ad altri (di solito ai sistemisti).
Per fare qualche esempio casuale:
- un aggiornamento di sistema
- un fallimento del disco
- una modifica ai permessi
- un bug in una dipendenza fuori dal mio controllo
- i Poteri Forti
Alla fine il problema era mio. Continuando le analisi, trovai il mio "Momento Zero", il giorno in cui la procedura aveva iniziato a fallire. C'era un bug, un bug che si scatenava col cambio dell'ora legale/solare.
Quindi: il mio ponte era crollato in pochi mesi, ma non fui licenziato. Anzi, ci facemmo tutti una grassa risata perché il motivo dietro a questo inspiegabile problema era davvero banale.
Ovviamente non stavo controllando una centrale nucleare, ma non pensiate che non esistano software critici. Ci sono stati attacchi hacker ad ospedali e fabbriche che hanno provocato danni reali e questo può solo aumentare.
L'infallibilità del software
Quindi ero sul letto d'ospedale con la mia tuta. E fu quello il momento in cui immaginai un mondo dove il software era infallibile, come una formula matematica. Le persone di questo mondo doveva concentrarsi solo sul cosa voler produrre, senza l'idea di realizzare qualcosa di robusto, perché l'infallibilità era insita nella loro disciplina.
Ovviamente un mondo del genere ho dovuto in parte immaginarlo: come ho già detto della precedente puntata, non è un romanzo di fantascienza hard. Qualcosa ho provato ad immaginarlo ma preferisco non dilungarmi oltre, finiremmo per parlare della tendenza che il mondo del software ha di reinventare iterativamente la ruota.
Ci basti sapere che nel racconto l'umanità ci è arrivata, in qualche modo lo ha fatto. E sono quindi nate generazioni di professionisti abituati all'infallibilità, che guardandosi indietro provano pena per i tempi barbari nei quali viviamo noi. Questi professionisti, gli "architetti del software" hanno quindi sviluppato capacità completamente differenti dalle nostre.
Il problema è che, per l'appunto, non è matematica e non lo sarà mai.
Se hai trovato questa ambientazione interessante, ti invito ad acquistare il romanzo, dove queste idee sono sviluppate per offrire al lettore un grande racconto giallo.