Artigianato della tecnologia

Il primo computer che ho usato era un Univac 1100. Era la fine del 1979, o forse l’inizio del 1980, e io frequentavo il terzo anno di ingegneria. A Roma il triennio di ingegneria si faceva a San Pietro in Vincoli, la prestigiosissima sede a due passi dal Colosseo, nelle immedia adiacenze del Mosè di Michelangelo. Proprio al triennio di ingegneria decidemmo, con il mio prode compagno di studi col quale ho condiviso l’intero corso di laurea, di specializzarci in elettronica, con un blando indirizzo informatico. Blando non perché non ci piacesse, ma perché l’informatica, i calcolatori, erano per l’appunto ancora all’inizio dell’incomincio. C’era IBM, con i suoi mainframe, detentrice di circa l’80% del mercato. E poi gli altri, a combattere e spartirsi il restante 20%.
Nei meandri della facoltà, in un cortile/corridoio che conduceva dalle aule agli Istituti, perversi luoghi dove assistenti e professori si dedicavano ad oscuri riti satanici e sacrifici di ignari studenti, in quel cortile/corridoio c’era il Centro di Calcolo (con le c maiuscole perché era un luogo quasi sacralizzato). All’interno c’erano quattro perforatrici, un lettore di schede al quale si accedeva solo se si aveva una specifica password, ed una specie di passavivande attraverso il quale si consegnavano agli operatori, rigorosamente in camice bianco (non scherzo), i pacchi schede da eseguire, che venivano restituiti unitamente al tabulato.

Il Vic 20, il C64 e l’Amiga dovevano ancora nascere. Era da poco stato rilasciato l’Apple I, e Bill Gates stava lavorando alacremente per realizzare l’MS-DOS, e collaborava con il progetto IBM che avrebbe visto la luce qualche anno dopo, dando origine al primo vero Personal Computer, il modello XT.

Le schede perforate erano l’interfaccia che tutti usavano, financo i professori o gli assistenti si presentavano con il loro paccozzo di schede e lo lasciavano lì. Il tempo macchina era parzializzato, se un programma andava in loop veniva “abbattuto” d’ufficio dopo (se non ricordo male) 3 minuti di CPU consumati. Per avere più CPU a disposizione era necessario farsi dare un’utenza specifica che andava richiesta alle competenti autorità.

Un terminale (terminale, eh, non PC) interattivo era una cosa che possedevano in pochi, avere uno spazio disco dove conservare i propri dati era un’idea da iperuranio, ed in generale le risorse di calcolo erano preziose, perché scarse. Oggi siamo abituati ad avere un iPad con 32GB di RAM, e qualcuno mi dice “ma… solo 32 giga? non li saturi subito?”. Quando sento cose del genere mi torna prepotentemente in mente il ricordo del VAX/780 (fabbricato da Digital Equipment Corporation) con il quale lavoravo nell’azienda dove ho iniziato. Era considerato un prodigio di modernità, ed aveva una RAM di 64KB (K, kilobyte, non mega o giga) e due dischi Winchester da 20MB (M, megabyte, non giga o tera). Ci lavoravamo in una ventina di persone…

Nessuna meraviglia quindi che si guardasse all’informatica, e specificamente al processo di produzione del software, come ad un qualcosa di artigianale. All’università ci insegnarono il FORTRAN, linguaggio usato nelle applicazioni scientifiche, mentre per le robe gestionali c’era il COBOL (inutile dire che tra cobolisti e fortranisti non correva buon sangue, i primi guardavano ai secondi con compassione pensando a quanti soldi muoveva il cobol, i secondi guardavano ai primi con malcelato disprezzo per la semplicità intrinseca dei programmi scritti in cobol confrontata con la maestosa complessità dei programmi fortran).

In questa consapevolezza di artigianalità si iniziò a parlare di Ingegneria del Software, il cui obiettivo era di gettare le basi per rendere lo sviluppo del software un processo industriale. Un certo James Martin, scrivendo libri e tenendo seminari sull’argomento, ha accumulato talmente tanti soldi da riuscire a comprarsi un’isola alle Bermude, dove tuttora vive. Per dire che l’argomento suscitava un interesse spasmodico per tutte le aziende del ramo, che allora nascevano come funghi. Il principale obiettivo dell’ingegnerizzazione del processo non era, come si potrebbe pensare, rendere il prodotto finale meno costoso, e quindi più profittevole. Per quanto possa sembrare strano, in quegli anni giravano talmente tanti denari che i costi non costituivano un problema. Il problema era star dietro alla domanda. Non si riusciva a fare abbastanza rispetto a quanto chiedeva il mercato. Avendo un buon prodotto, guadagnare quote di mercato era una bazzecola. Si iniziava appena ad intravvedere quale potenzialità avesse l’informatizzazione. Non solo sul piano squisitamente gestionale ma anche come ausilio a processi di produzione, cominciavano ad arrivare le prime workstation con programmi di impaginazione editoriale, ad esempio.

Cavalcare quest’onda era solo apparentemente facile. Ho visto piccole aziende nascere, crescere e diventare grandi aziende. Ma ho visto anche parabole velocissime di nascita, crescita e collasso. In quegli anni fu coniato il termine “professional” per definire un impiegato che aveva una professionalità spinta, richiesta dal mercato, e che quindi doveva essere considerato e trattato adeguatamente, sia in termini squisitamente monetari e carrieristici, sia soprattutto in termini di mansioni: ad un professional non si dovevano assegnare dei compiti ma degli obiettivi.

Eravamo considerati dei guru dai nostri clienti. Sacerdoti che si recavano da loro a celebrare gli antichi misteri. Che arrivavano e miracolosamente risolvevano problemi apparentemente insolubili, che facevano funzionare meglio, a volte incredibilmente meglio, il sistema esistente.

E anche questo non fa meraviglia, visto che, come detto, si trattava di processi artigianali. Ed in forza dell’artigianalità i problemi, i crash, i blocchi improvvisi, erano all’ordine del giorno. E ricordo un numero indefinibile di notti passate a sistemare, aggiustare, provare, verificare, riprovare, rifare daccapo. Cambia quel parametro, aggiusta quell’altra cosa, sistema quello, smonta quell’altro.

Bene. Tutto questo accadeva trent’anni fa. E oggi?

Oggi, come ho avuto modo di realizzare compiutamente la scorsa settimana e nella giornata odierna, non è cambiato proprio niente.

Siamo artigiani, il processo di produzione e gestione di sistemi software complessi è totalmente artigianale, e non c’è salvezza. Mi piacerebbe qualcuno avesse inventato un comando “whatschanged”, che listasse automaticamente tutti i cambiamenti del sistema, ma una roba intelligente, che vada a indagare sui parametri di sistema, sulle relazioni che ci sono tra i vari parametri, ed evidenzi le incongruenze. Perché la storia dei parametri è come in tante situazioni, alzi un parametro per migliorare qualcosa ma non alzarlo troppo ché se no risolvi un problema e ne crei un altro. E se alzi x devi forse anche cambiare y perché altrimenti si scassa qualcos’altro.

E poi ti imbatti in una conferenza come questa di Kevin Slavin che riporto qui sotto (a proposito, TED è un sito e un concetto che suggerisco a tutti di andare a capire; nessun timore sono tutti video sottotitolati in quasi tutte le lingue del mondo; basti sapere che il sottotitolo del sito è “Ideas worth sharing”, idee che vale la pena di condividere). Grazie a Giovanni Scrofani e a Gilda35, il post lo trovate qui.

Qui si parla di algoritmi che vanno a cercare ottimizzazioni da microsecondi, e a volte nanosecondi. Tutti prodotti artigianalmente. Tutti prodotti a manina come un muratore che tira su un muretto con la sua malta, la cazzuola, e non ha altro che un filo a piombo per capire se sta tirandolo su diritto. Ecco, il problema è che questo muretto tirato su all’antica deve sostenere l’economia mondiale. Perché gli algoritmi di cui si parla nel video sono quelli usati dai grandi investitori istituzionali per comprare e vendere sui principali mercati azionari.

E quello che da addetto ai lavori mi sento di condividere è che la perfezione non esiste, e anche l’algoritmo più efficace, più astuto, più testato, può avere un cedimento, un bug (vedi storia di Poste Italiane). E poi possono verificarsi fattori imponderabili, imprevedibili. Qualcuno che cambia il parametro x e si dimentica di cambiare y. Lì per lì non succede nulla ma poi, magari dopo una settimana, scoppia tutto, e una batteria di tecnici sta a rompersi la testa per una-due settimane per capire cosa è successo. O magari per uno-due giorni. Ma quando si spendono giorni su un sistema “normale”, si riesce a venirne fuori con qualche nottata e un po’ di schiaffi presi dal cliente, nel caso in cui si stiano influenzando i destini del mondo si rischia di non uscirne proprio fuori, o di fare dei casini irreparabili.

Non so veramente come concludere, forse la conclusione è che non bisogna mai riporre troppa fiducia, o meglio fiducia cieca, nella tecnologia. Perché in fondo alla base della tecnologia c’è sempre la fallibilità umana.