iDieci iComandamenti

Un uomo barbuto è noto soprattutto per una sua frase: "La religione è l'oppio dei popoli". Una frase interpretata in tante sfumature diverse ma che fa capire come l'essere umano, più o meno dotto, ha sempre cercato una facile risposta a qualcosa a lui ignoto.

Un prete del mio paese, tanti anni fa, ci veniva a trovare spesso mentre facevamo catechismo all'oratorio (ebbene sì, anche io ho un passato oscuro). Fra le varie "prediche" gratuite, un giorno ci fece una domanda che non capii per tanti anni. O meglio, non capii la risposta. Ci chiese più o meno: "Chi sono i nuovi dei a cui l'uomo si sta paurosamente avvicinando?". Qualcuno facendo il figo buttò lì un Allah, venendo però tacciato dall'antipatico prete. La risposta che ci diede fu: "Il dio calcio! Il dio televisione". La religione cattolica voleva il monopolio sulla distrazione di massa. Ma stiamo parlando dei primi anni '90. Quell'odioso prete non poteva neanche immaginare ciò che sarebbe arrivato negli anni a seguire.
Nei decenni successivi sono arrivati tanti nuovi profeti. Ma il migliore, colui che ha centrato l'obiettivo è Steve Jobs.

La sua storia ha qualcosa di biblico. La parte per me più bella è quella iniziale, ben raccontata nel film I Pirati di Silicon Valley, in cui il giovane Steve riesce a sviluppare al meglio un impero, per poi riuscire a perderlo. Una storia dalle tante morali.

Quello che è successo dal 1997, dopo il reinserimento nella società da lui stesso fondata, ha però l'aspetto più profetico. Arrivati in un'era tecnologica in cui si poteva realizzare qualcosa di inimmaginabile anche solo dieci anni prima, l'ormai attempato Steve inizia a dettare legge su ciò che sarebbe stato un percorso che tutto il mondo avrebbe seguito. 

Ha imposto la religione della tecnologia. 

Ora, grazie a lui, il popolo ha lasciato il rosario nel comodino e ha impugnato lo smartphone. Nessuno può più vivere senza il suo tablet, anche se non sa bene cosa farci. L'importante è averlo e avere fede nelle App che lo store gli ha donato (a pochi €).

Steve ha dettato legge:

1) Non avrai altro smartphone all'infuori dell'iPhone.

2) Non nominare il nome di Google invano.

3) Ricordati di santificare l'Apple Store. 

4) Onora il tablet e la mela.

5) Non jailbreakkare.

6) Non comprare App impure.

7) Non rubare (compralo!)

8) Non brevettare falsa testimonianza.

9) Non desiderare il sistema operativo altrui.

10) Non desiderare l'App Store altrui.

Apple.

Dieci Piccoli Bug

Non amo scrivere molto del mio mestiere. Questo blog è un luogo di evasione e riflessioni trasversali. Spesso passo da qua cercando proprio di staccare dalle 40 ore settimanali che mi vedono concentrato in astruse righe di codice. Il mio lavoro, inoltre, è di difficile comprensione per chi non abbia mai avuto a che farci e quindi ho sempre il timore di parlare di cose note ai colleghi e incomprensibili per chi non abbia un minimo di cultura informatica. Oggi però voglio provare a descrivere le fantastiche avventure che possono celarsi dietro ad un Bug.

Cos'è il bug? Per i programmatori partenopei potrebbe essere l'apostrofo invisibile fra le parole chitemuort. Per chi non ha idea della continua frustrazione che deve provare l'operaio del terzo millennio (il programmatore), proverò a descrivere uno degli elementi più sadomasochistici del mio lavoro.

Capita raramente, per vari motivi (alcuni descritti in questo mio post dell'anno scorso), di scrivere un software perfetto, privo di errori. Per questo si passa più tempo a fare test che a scrivere codice. Mentre tutti gli errori grossolani sono subito evidenti, i bug a cui mi riferisco in questo post sono quelli che si nascondono (a volte anche per anni) dietro una particolare combinazione di concause.
Capita così, per esempio, che l'inserimento dei dati su una pagina di un sito internet su cui stai lavorando funzioni benissimo sul tuo PC e su quello dei tuoi colleghi ma, una volta pubblicato nel server di collaudo, vada in errore. 

Si parte così alla ricerca del bug. La ricerca può durare minuti, ore o anche giorni. La conseguenza finale (la pagina web che va in errore) è spesso l'ultima delle conseguenze di una serie di reazioni a catena che si innescano fra le varie istruzioni del codice: questo comporta una ricerca non banale.
Il bug ci fa così diventare uno e trino: carnefici, vittime ed eroi. Dobbiamo infatti risolvere velocemente l'intricato enigma che noi stessi abbiamo generato involontariamente, sottraendo tempo al lavoro rimanente.
C'è da dire che a volte ci ritroviamo anche a correggere software scritto da altri colleghi, ma in questi casi, come il gruppo di lavoro di House, ci si unisce e si fa brainstorming. Per questo si diventa tutti vittime, carnefici ed eroi. Si ipotizzano svariate teorie, si fanno prove, controprove e si cerca di arrivare alla causa: l'origine del male. Ma, proprio come in una serie-tv procedurale, quando ci sembra di essere vicini alla soluzione ci si ritrova con un buco nell'acqua. Il bug sembra quasi che ti derida, in questo nascondino virtuale in cui la logica sembra essere andata in ferie. Ad un certo punto tutto sembra essere stato ipotizzato, ogni controllo essere stato fatto. E poi non rimase nessuno, come il titolo del bellissimo romanzo di Agatha Christie (tradotto tristemente in "Dieci Piccoli Indiani"). Spesso, proprio in quel momento vedi la luce in fondo al tunnel (sperando che non sia un treno che ci venga contro, come dice un mio collega) e trovi l'indizio che ti porta sulla giusta strada. Percorrendo a ritroso tutti i passaggi arrivi così a scoprire il colpevole!
La soddisfazione che si prova in questi casi è quasi orgasmica: veloce ma intensa. Si prova un piacere aggiuntivo se poi scopri che il problema è dovuto ad una causa esterna al tuo software.
Un lavoro strano il nostro, forse un po' masochista, forse un po' operaio, forse un po' da matti.
Un lavoro che può dare però tante piccole soddisfazioni.

Fantozzi aveva ragione

Chi non ha mai visto un film di Fantozzi alzi la mano! Lei, in terza fila, esca da questo blog!

Fantozzi può far più o meno ridere; sicuramente la satira sociale degli ultimi film si è annacquata quasi nello stile cinepanettone in voga negli ultimi venti anni. Però, soprattutto nei primi due film tratti dai medesimi romanzi scritti da Paolo Villaggio, il mite rag. Fantozzi incarna alla perfezione il disagio sociale del dipendente italiano poco avvezzo al consumismo importato dagli U.S.A. A partire dagli anni sessanta si è vissuto un periodo storico particolare per chi, nato nella piena seconda guerra mondiale, si ritrovava in un ambiente classista e spietato: il terziario moderno.

Quel sistema piramidale, dal megadirettore galattico alla base dei dipendenti schiavizzati, ha dominato in questi ultimi quarant'anni fino ai giorni nostri. L'Italia si è fermata allo stile fantozziano, applicando quel pattern a quasi tutti i suoi settori aziendali. Questo ha avuto senso per i primi decenni, ma in questi ultimi anni, in un periodo in cui uno smartphone può sostituire il ruolo di tre livelli diversi, ci si ritrova un esubero di persone in grado ormai solo di scaldare sedie.
Nel mondo informatico il paradosso è ancora più accentuato. Mentre negli U.S.A. le più grandi aziende (non solo Google) stimolano e ottimizzano il lavoro dei propri dipendenti con ambienti di lavoro ottimali e pensati per loro, in Italia ancora si fa fatica a immaginare uno stile diverso da quello di Fantozzi.
Per fortuna la società per cui lavoro si distacca da questi sistemi ormai obsoleti, però quando, di passaggio presso un cliente, mi ritrovo a lavorare presso un sottoscala, il dubbio mi sovviene.

Le cinque fasi dell'elaborazione del lutto informatico

Il mio è un lavoro particolare, bellissimo e frustrante allo stesso tempo. Proiettato nel futuro ma ancorato alle tipiche incomprensioni che hanno segnato la storia: io faccio il programmatore.

Una volta programmare era una delle tante cose che sapeva fare un "Informatico". I veri pionieri di  questo lavoro erano dei factotum: dal microchip alla ricerca, dal software all'hardware. Col passare degli anni, anche questa disciplina è stata frammentata e burocratizzata, rendendo così il programmatore l'operaio del terzo millennio, alle prese con la sola creazione di software.

Queste armate Brancaleone dell'informatica si ritrovano spesso a dover affrontare il duro compito di creare un programma le cui funzionalità sono definite in un documento (più o meno dettagliato), avendo a disposizione il minor tempo possibile. Anche se non siete del mestiere, provate a immaginare la difficoltà di creare in fretta un software che sostituisca un lavoro fino a quel momento cartaceo o poco più, senza aver mai saputo nulla di quel lavoro. I clienti sono i più disparati e, di conseguenza, ci si ritrova in ogni progetto a dover imparare qualcosa di nuovo: da come viene amministrata l'energia a come viene gestito un lavoro ministeriale e così via. Questo è il bello del mio lavoro: conoscere tanti lavori. Purtroppo però il più delle volte, l'analisi (la fase iniziale di un progetto in cui gli analisti capiscono cosa il cliente vuole che si realizzi) è fatta male, di fretta e da altre società. I programmatori si ritrovano così a realizzare un software per un cliente senza mai parlare col cliente stesso. Un po' come correre con un polso legato alla caviglia.

Questo modo di lavorare comporta, nella maggior parte dei casi, la non perfetta realizzazione al primo tentativo di ciò che il cliente vuole (tenete presente che spesso neanche il cliente ha un'idea precisa di cosa voglia prima di vederselo di fronte). Questo implica che ad un certo punto il programmatore si accorga che ciò che sta realizzando sarà, in un certo qual modo, un fallimento. 

Quando ci si rende conto di questo, si attraversano le cinque fasi dell'elaborazione del lutto informatico.

1) Negazione o Rifiuto: in questa fase non si vuole credere che il progetto stia prendendo una direzione sbagliata. Non si dà retta al collega che fa notare l'evidenza. Tipiche le frasi: "Ma come è possibile che l'analisi sia sbagliata?", "Ma è possibile che il cliente voglia veramente questo?", "Non ci posso credere!".

2) Rabbia: in questa fase il programmatore vorrebbe azzannare la tastiera e qualsiasi collega gli capiti sotto tiro, soprattutto il collega che (secondo lui) è responsabile principale del fallimento. Si rischia di rovinare rapporti,  a volte anche amichevoli, e ci si guarda in cagnesco. Tipiche la frase: "Perché proprio a me?!"

3) Contrattazione o Patteggiamento: in questa fase si cerca di capire quanto del lavoro fatto sia da buttare nel cesso e quanto sia effettivamente quello che il cliente voleva. Si cerca quindi di correggere il tiro, sperando di avvicinarsi il più possibile al vero obiettivo. Tipiche le frasi: "Se rifacciamo questa parte, forse al cliente non farà troppo schifo", "Impostiamo per bene le prime funzionalità, almeno inizia con qualcosa di corretto".

4) Depressione: in questa fase si capisce che ormai il software in questa sua prima versione è spacciato, inutile ogni tentativo di refactoring. Ci si rende conto che l'obiettivo è distante o, peggio, ancora ignoto e si deve quindi arrivare alla consegna, pronti a ricevere le critiche e le eventuali richieste di modifica. Tipiche le frasi: "Questo software non finirà mai", "Questo software non funzionerà mai!".

5) Accettazione: quando si arriva all'ultima fase ci si mette l'anima in pace e si capisce che ormai quello che si sta realizzando sarà un parente lontano di ciò che il cliente si aspettava. Se si è stati bravi, il codice è pronto però a essere corretto velocemente, una volta ricevute le giuste indicazioni.  Tipiche le frasi: "Andiamo avanti così, inutile lottare ancora", "L'analisi fa schifo, non è colpa nostra".

Una volta superate queste cinque fasi, il programmatore è pronto a iniziare un nuovo progetto e riprendere il ciclo dall'inizio.