I Piu Bei Bachi Software. 1p3z6g

Roberto Bera

I piu bei bachi software.

“Io ne ho viste cose che voi umani non potreste immaginarvi: navi da combattimento in fiamme al largo dei bastioni di Orione, e ho visto i raggi B balenare nel buio vicino alle porte di Tannhä.”

(Rutger Hauer/Roy Batty)

I saw the best minds of my generation destroyed by madness...

(Allen Ginsber, How)

Ho visto la gente della mia età andare via.

lungo le strade che non portano mai a niente

(F.Guccini, Dio è morto)

UUID: e62bec84-e3bb-11e5-9793-0f7870795abd

Questo libro è stato realizzato con StreetLib Write (http://write.streetlib.com) un prodotto di Simplicissimus Book Farm

Glossario

CNC

Computer Numerical Control. Si tratta di computer che gestiscono il lavor

GPS

Global Positioning System. Non sto a dettagliare di più, perchè quando ne

ISTQB

International Software Testing Qualfication Board. Organizzazione interna

Log

Termine che l'informatica ha importato dalla marina. Il “log” era un antico

Part-program

Programma eseguito dal CNC. Contiene le istruzioni per le macchine uten

PDP 11

Programmed Data Processor model 11. Una serie di mini-elaboratore della

PLC

Programmable Logic Controller. E' uno strumento hardware utilizzato nell

PMBoK

Project Management Body of Knowledge. E' un testo pubblicato dal Proje

RAID

Redundant Array of Independent Disks. Tipo di architettura hardware utili

Stakeholder

Relativamente ad un progetto, gli stakeholder sono le persone, i gruppi o l

VAX-11

Virtual Address eXtension. Famiglia di mini-elaboratori della Digital Equ

VT100

Terminale spesso collegato ai PDP-11. Aveva 24 righe di 80 caratteri. Ved

Zappos

Azienda statunitense che vende scarpe e abiti on-line. Il suo modello organ

Questo glossario è stato redatto solo per seguire un assodato formalismo. L'autore è consapevole che se un lettore trovasse qualche termine insolito o qualche sigla sconosciuta, andrebbe su internet a cercarne il significato.

De pulchritudo bugorum softueris

Il manuale ISTQB ,al punto 1.1.2 parla di bug, defect, error, failure, fault, mistake. Sostanzialmente error e mistake sono sinonimi e indicano ciò che l'uomo produce per sbaglio: o involontariamente o perchè la sua visione è errata. Questi “error” o “mistake” generano dei “defect”, detti anche “bug” o “fault”. Quando questi defect vengono eseguiti, il sistema ha un “failure”. Pur facendo tanto di cappello alle best pratices di ISTQB, per motivi puramente estetici, mi permetto di chiamare “bug”, nel titolo tradotto in bachi, sia l'errore, sia il difetto, sia il “failure”: tutto ciò che causa una differenza tra quello che il sistema fa effettivamente e quello che ci si aspettava fe. In questa parte introduttiva, mi propongo di analizzare se, quando, come e perchè ad un software bug possa essere associato l'appellativo di bello. Dostoevskij fa dire ad un suo personaggio, il principe Miskin,“La bellezza salverà il mondo”. In virtù di questa sentenza, che verrà poi ripresa da altri intellettuali in vari contesti, io devo escludere dalla bellezza tutti i bachi nel software che, anziché salvare, hanno causato danni. Una centralina automotive che non risponde più ai comandi del guidatore o peggio, se li inventa, un'apparecchiatura elettromedicale che impazzisce, una transazione bancaria che scompare, non possono essere belli. Analogamente non possiamo considerare belli un incendio, una slavina, una burrasca in mare, un torrente che straripa, se questi lasciano vittime o causano danni, anche se questi fenomeni ci mostrano effetti speciali visivi ed audio. Escludo pure dalla bellezza i bachi bolsi e banali che si verificano di tanto in tanto. Esemplifico con il più bolso, ovvio, scialbo, ripetuto bug che con frequenza almeno annuale ogni tanto appare e, mi vergogno dirlo, ma una volta è scappato anche a me, seppur l'abbia scovato quasi subito. Si tratta dello scambio del confronto con l'assegnazione nei programmi scritti in C e nei liguaggi da esso derivati. Infatti in questi linguaggi il confronto viene fatto con il simbolo “uguale” ripetuto due volte (“==”), mentre l'assegnazione con il semplice “=”

Il programmatore ha in mente: se la variabile a è uguale alla variabile b, allora si fa qualcosa, per esempio azzerare la variabile c, altrimenti non lo si fa. Dovrebbe quindi scrivere: if (a==b) c=0; Ma lo sventurato scambia il simbolo di confronto con con quello di assegnazione e scrive if (a=b) c=0; cosicchè assegna ad a il valore di b e poi, qualsiasi valore avessero in precedenza a e b, azzera c. Questo errore non ha niente di bello. Previsto e prevedibile. I tool di verifica automatica del codice lo sanno. In certi linguaggi, come il php, si usa anche il simbolo di triplo uguale (“===”) ma io non posseggo ancora una letteratura clinica sulla confusione di questo simbolo. Gli errori belli, sono quelli in cui si riesce a cogliere un certo umorismo ebraiconewyorkese, come in certe citazioni di Woody Allen. La logica è rispettata, ma il contesto è stravolto. Di recente ho letto “Mathematics and Humor: A Study of the Logic of Humor” di John Allen Paulos. L'autore esamina alcuni casi di “logica sconvolta”. In questi ho ritrovato la bellezza di certi bug. Ma la bellezza principale è la caccia al baco, il processo di ricerca del colpevole. La letteratura “letteraria” in molte situazioni descrive i nostri processi mentali. Gli effetti sono spesso affascinanti. Abbiamo pagine e pagine sul processo di innamoramento e disamoramento, sui rimorsi, sulle sopravvivenze di retraggi del nostro ato nell'inconscio, sulle decisioni da prendere per il futuro, ma salvo rare eccezioni non abbiamo descrizioni sui processi di scoperta delle cause di un certo evento negativo. Le rare eccezioni che mi vengono in mente sono i romanzi e racconti di Georges Simenon che hanno come protagonista il commissario Maigret e il romanzo "La chiave a stella” di Primo Levi. Nei gialli di Agatha Christie con Miss Marple ed in quelli di Rex Stout con Nero

Wolfe, per dire dei casi estremi, i due detective se ne stanno appartati a rimuginare, poi nelle ultime pagine, come per magia, ti spiattellano colpevole, movente e ricostruzione della scena del delitto. Invece con Maigret, il lettore segue i suoi movimenti, lo accompagna sulle le tracce, a volte giuste e altre volte inutili, che lui percorre per far luce sul delitto. Il colpevole, il suo movente e la sequenza delle azioni da lui commesse, è come se emergessero dalle nebbie che Maigret pazientemente dirada. Meglio ancora è Primo Levi in alcuni racconti de “Il Sistema Periodico” ma soprattutto nel romanzo “La chiave a stella”. In questo romanzo mi ci sono ritrovato per tre motivi. Innanzitutto la lingua. Avevo letto un libro di José Miguel Garcia, un biblista, secondo cui il Vangelo di Marco fu “pensato” in aramaico e probabilmente in tale lingua ha avuto un prima stesura. Poi è stato redatto in greco, ma con una traduzione così letterale che lascia trasparire il testo aramaico, almeno per il bibilista che conosce entrambe le lingue. Analogamente, ne “La chiave a stella” io, che più modestamente del reverendo biblista, conosco l'italiano ed il piemontese, noto che l'io narrante, il dottor Levi, ed il suo intelocutore, il signor Faussone, pensavano in piemontese, dialogavano in piemontese, e Levi ha scritto il testo in italiano facendone una traduzione molto letterale. Il secondo motivo è la trasferta in Russia per lavoro. Anche a me è successo di trovarmi in Russia per lavoro, ma purtroppo io non ho incontrato nessun Tino Faussone. Qualche italiano degno di stima l'ho anche incontrato, ma la maggior parte degli italiani in Russia avevano atteggiamenti per cui mi vergognavo di essere loro compatriota. Allora la Russia era l'URSS ed il rublo aveva un cambio “fittizio”. Se riuscivi ad introdurre surrettiziamente dei dollari, e a fine anni 80 ci riuscivi, quando li cambiavi al mercato nero, ti riempivano di rubli. A certi italiani, il vedersi trasformare un terzo dello stipendio mensile in quello che era lo stipendio annuale di un impiegato di buon livello russo, dava piuttosto alla testa: lascio al lettore immaginare i dettagli di questo "dare alla testa". Il terzo motivo del mio apprezzamento per "La chiave a stella" è il capitolo “Acciughe”. Mentre nella maggior parte del testo, il protagonista è il signor Faussone, in questo capitolo Levi racconta della sua attività. La ditta per cui lavorava aveva venduto un particolare tipo di vernice ai russi. Tutti i test fatti nel laboratorio in Italia erano andati bene. Nello stabilimento russo, talvolta il processo produttivo funzionava come previsto, ma altre volte no, la vernice era

“guasta”. Salto il racconto di Levi nello scoprire l'inghippo, leggere il testo originale è meglio del mio riassunto. Ma il bello di certi bachi software, come per il problema delle vernici, è la non ripetitività. Se “qualche volta non funziona”, ma il più delle volte sì, crollano inveterate certezze risalenti al XVIII secolo, prima fra tutte la riproducibilità degli eventi. La non riproducibilità degli eventi è abbastanza frequente nei sistemi real-time, argomento prevalente del mio lavoro. Infatti “pezzi codice” sono eseguiti ripetutamente, ciclcicamente migliaia di volte ma in contesti sempre diversi, contesti che non sono definiti solo dalle note “variabili di input”. In questo caso l'approccio analitico mostra i suoi limiti. Tradizionalmente si dice che occorre separare i casi, verificare che ogni singolo modulo funzioni, essere sicuri di circoscrivere l'errore... ma tutto ciò non serve quando per mille volte funziona e la milleunesima no. Qui occorre invece fare esattamente l'opposto. Invece di analizzare il dettaglio occore come fare un o indietro o salire metaforicamente su uno sgabello: insomma avere un orizzonte più vasto per capire bene il contesto in cui quel software abitualmente funzionante, talora non funziona. Poi ridiscendere nel particolare e colpire. La capacità di muovere lo zoom avanti ed indietro, per prestare attenzione ai particolari, ma anche capire il contesto più vasto in cui si collocano, è un esercizio di grande utilità esistenziale. Nel debugging del software mostra la sua validità. Vi sono altre due considerazioni da fare sul debugging del software, ma non sono molto politically correct. La prima è che, nonostante tutte le tecniche di problem solving, prese anche da altri contesti come i diagrammi di Ishikawa e altre metodologie analitiche, di fatto prima si intuisce dove è l'errore, poi razionalmente si dimostra che l'errore è quello. Dirlo sembra una bestemmia. Tutta una certa ideolgia positivista vorrebbe che l'errore si trovasse procedendo razionalmente o dopo o. Io non ho mai visto questo approccio portare alcun risultato, o comunque, quando applicato è di una lentezza spaventosa ed esasperante. Mi spiego: non è che l'esame analitico non serva, ma questo è utile per generare degli input ad un altro cervello che sta dentro di noi, molto veloce e taciturno, che produce ipotesi: “mi è venuto in mente che potrebbe essere...” poi il cervello razionale vaglia l'ipotesi. So che “venire in mente” per un ingegnere è blasfemia: è una frase che evoca, quando va bene lo sciamanesimo, quando va male l'ispirazioni degli artisti romantici. Sarebbe bello se in futuro qualche esperto in neuroscienze affermasse

che invece funziona proprio così. La seconda considerazione, poco politically correct, è l'intervento dal manager. Uno degli interventi meno riusciti dei manager a questo punto è chiedere: “Quanto vi manca a finire?” o se il manager fosse reduce da un corso sulle relazioni positive con i dipendenti “Quanto tempo vi serve ancora per finire?” Ora, se si trattasse di un lavoro sequenziale, che ne so, spostare degli scaffali o asfaltare la Via Emilia, ma anche eseguire una serie di test predefiniti, non ci sarebbe problema a rispondere. Ma nel caso del baco nascosto, che in teoria non avrebbe neanche dovuto esserci, quella è una domanda veramente cretina, che oltre fare perdere il filo ai tuoi ragionamenti, ti fa mandare in bestia, facendoti ancor più perdere il filo. Uno si consola con un riferimento colto. Nei gialli di Maigret, almeno in una riduzione televisiva con il sommo Gino Cervi nelle vesti del commissario, ogni tanto il giudice istruttore chiede “Quanto tempo le occorre ancora prima di risolvere il caso?” Be' tutto il mondo è paese. Ricordo un episodio patetico, accoduto molto tempo fa. Stavo scervellandomi su un argomento e lo dissi ad un collega più anziano di me. Evidentemente lui aveva dovuto riportare la situazione a qualche superiore e l'informazione ha scalato la piramide aziendale. Nel frattempo il problema era stato risolto, ma come è noto, la soluzione di un problema apre nuove strade e queste strade ti portano ad evidenziare altri problemi. Ero concentrato su uno di questi, quando un capo pesantemente gallonato mi chiese come stava andando, e si mise a farmi una paternale d'incoraggiamento e di motivazione sull'importanza dello sviluppo un questione. Io che avevo la testa sul problema attuale, ci misi un po' a capire che lui stava parlando del prolema già risolto un po' di tempo fa. Abbiamo perso tempo in due. Ma lui sarà stato capace di autoconvincersi dell'utilità del suo intervento e quindi di essersi guadagnato lo stipendio mensile. Ancor più patetici sono i manager che vogliono essere collaborativi, facendo delle domande che c'entrano come i cavoli a merenda. Ah, Zappos! Ah, Valve! Ah Management 3.0!

Pur non sapendone nulla di chimica, ho gradito molto “La chiave a stella” e alcuni racconti de “Il sistema periodico”. Io non possiedo l'abilità narrativa di Primo Levi, ma spero che anche chi non ne sa nulla di informatica possa essere

interessato a leggere i miei racconti.

Relativismo culturale nel software

Quando iniziai a lavorare ero giovane. Maurizio era già vecchio. Non aveva molti anni più di noi, ma quei pochi li portava in modo molto greve. Vestiva in grigio o in marrone e a volte indossava un pullover bordeaux, aveva il pizzo, la pancetta, fumava le MS blu, parlava in modo catarroso e stentoreo, viaggiava in Lancia Beta, auto da vecchi. Sapeva comunque un sacco di cose e le pontificava. Un giorno decise di fare a noi giovani un test. Scrivere, in un linguaggio qualsiasi, anche non formale, un programma tale che se l'input è 1 l'output sia 2 e se l'input è 2 l'output sia 1. Non ricordo cosa scrissero i colleghi, ma Maurizio elencò le nostre risposte alla altre accumulate negli anni in cui si divertiva a fare questo test. Ora ne ricordo solo alcune. Allora si lavorava in assembler o fortran e si facevano le “analisi” con il flow-chart, ma ora riporto per comodità le soluzioni in uno pseudo-C. 1° Soluzione

if (input == 1) output = 2; if (input == 2) output = 1; exit; Questa soluzione risponde perfettamente al requisito. Se input non valesse né 1 né 2, output non verrebbe valorizzato.

2° Soluzione if (input == 1) output = 2;

else output = 1; exit; Questa soluzione risponde al requisito, ma “inventa” il caso in cui input non valesse né 1 né 2; output in questo caso vale 2. Esite, ma non la riporto ed il lettore la intuisce benissimo, una soluzione simmetrica, che gestisce prima il caso input==2. Entrambe non contraddicono il requisito.

3° Soluzione output=3-input; exit; Questa soluzione risponde al requisito, ed “inventa” altre risposte per i casi in cui input è diverso sia da 1 che da 2.

4° Soluzione output = NOT (input); exit; Dove per NOT si intende la negazione bit a bit. Anche questa operazione risponde al requisito, ammesso che input sia di due bit, ed inventa “altri” valori ancora per input diverso sia da 1 che da 2 (cioè 0 o 3).

5° Soluzione (misto della 3 e 4) output= 3 XOR input; exit;

6° Soluzione: switch (input){ case 1: output=2; case 2: output=1; default: ERRORE } exit; Questa famiglia di soluzioni gestisce esplicitamente anche il caso in cui input non abbia i valori specificati. Fa così anche la soluzione che allora proposi io, sebbene l'implementazione sia diversa.

Mia soluzione Definizione di tabella {KEY=1 VALUE=2, KEY= 2 VALUE=1}, output = Tabella(KEY=input).VALUE; exit; Va da sé, che se input non era una chiave presente in tabella, la ricerca in tabella avrebbe segnalato “Elemento non trovato” o qualcosa di simile. Secondo me questa era una soluzione altamente configurabile. Se cambiavano i requisiti, bastava cambiare la tabella, senza cambiare il codice. Ammetto di essere un ingenuo a pensarla così. Il mio primissimo lavoro, anno 1980 fu su un computer Philips, che a quei tempi lontani era ormai obsoleto.

Notavo l'ironia dei colleghi più maturi, quando nel manuale trovavano byte "reserved for future use". Quanti campi di database avrei poi visto lasciati liberi e mai utilizzati! Quante opzioni mai selezionate!.... Eppure la natura umana è questa: quando uno fa qualcosa, suppone sempre che la cosa intrapresa abbia un seguito e ipotizza la strada con cui questo seguito si manifesterà.

Torno al test di Maurizio. Questo aneddoto apre due argomenti. Ecco il primo: “qual'è la soluzione migliore?” per rispondere alla domanda riferisco, con una mia traduzione personale, quanto dice Jurgen Appelo nel suo Management 3.0

Ogni problema ha soluzioni multiple Le soluzioni dipendono dal contesto del problema Cambiare il contesto richiede di riconsiderare le soluzioni Per ogni soluzione strana c'è un contesto in cui è la migliore Le soluzioni cambiano il contesto e quindi esse stesse. La semplicità ha bisogno di comprendere la complessità Non è possibile predire la soluzione migliore.

E rincaro con la citazione di H. L. Mencken, personaggio che, per quanto se ne deduce da wikipedia era piuttosto sgradevole, ma questa citazione è tosta: “Per ogni problema complesso, esiste una risposta semplice, chiara e sbagliata”.

Il secondo argomento è la riusabilità del codice. Supponiamo che il moduletto dell'esempio entri in un “repository”, una qualche libreria in uso in azienda. Supponiamo che diventi una funzione, sostituiamo “exit” con “return (output)”

Supponiamo che un malcapitato programmatore la chiami assegnando input il valore 4 (i requisiti specificavano solo cosa dovesse fare per 1 e 2).

1 Soluzione

Dato non assegnato. Risultato imprevedibile. Un buon compilatore avreb

2 Soluzione

1

3 Soluzione

-1

4 Soluzione

Dipende dal come è definita la variabile. Se fosse 8 bit senza segno sareb

5 Soluzione

Dipende dal come è definita la variabile. Se fosse 8 bit senza segno sareb

6 Soluzione

Segnalazione di errore

Mia Soluzione

Segnalazione di errore

Tutto questo per una questione molto banale, figuriamoci per casi un po' più complicati. Divertente neh?

Il boomerang magico

Preambolo folkloristico. Quando ero ragazzino, per televisione, sull'unica rete allora esistente in Italia, per un certo periodo veniva trasmessa una serie di telefilm d'importazione, intitolata “Il boomerang magico”. Si trattava appunto di un boomerang che quando veniva lanciato, faceva sì che il tempo si fermasse per tutto l'universo, meno che per il boomerang stesso che continuava il suo volo e per chi l'aveva lanciato. Tutti rimanevano immobili ed inconsapevoli di ciò che accadeva, poi quando il boomerang aveva finito il suo volo ed era ripreso dal lanciatore, tutti riprendevano quello che stavano facendo, come se nulla fosse accaduto. Ovviamente il lanciatore, in quel breve lasso di tempo riusciva a compiere qualche azione, come far sparire un documento, scaricare la pistola di un “cattivo” che stava per sparare, comunque qualcosa di risolutivo nella trama della puntata. La magia del boomerag si è verificata nella realtà grazie ad un baco nel software.

Piattaforma Tecnologica: PDP 11 – programmazione in Fortran e Assembler.

Contesto operativo: Factory automation

Svolgimento del fatto: 1984 negli Stati Uniti.

Progetto: Linea flessibile di produzione. Una notevole società di automazione industriale italiana, che chiameremo Babau, aveva fornito ad un'azienda metalmeccanica statunitense un'area di fabbrica automatica.

Vista dall'esterno: venivano portati dei semilavorati grezzi in ghisa, usciti della fonderia o da qualche o precendente nel processo produttivo. I semilavorati erano caricati nei “cestoni” adatti al loro formato, che venivano introdotti in un magazzino “buffer” temporaneo. I cestoni contenevano tutti lo stesso tipo di particolare, ma cestoni diversi contenevano particolari diversi. Intanto, al di là del buffer vi una rulliera che trasportava degli “attrezzi” di diverso tipo a cinque macchine a controllo numerico, ad una stazione di lavaggio guidata da un robot, ad una stazione di carico scarico. (vedi illustrazione 1 )

Illustrazione 1: Stazione di Carico/Scarico attrezzi

I nostri cestoni giungevano in coppia alla stazione di carico scarico ad ogni arrivo dell' attrezzo in grado di ospitarli. L'operatore smontava i pezzi lavorati dall'attrezzo nel "giro" precedente e li metteva nel cestone in riempimento, estrava dal cestone in svuotamento dei grezzi che montava sull'attrezzo, segnalava la cosa su un terminale, e l'attrezzo partiva sulla rulliera per far lavorare questi grezzi: tornire, alesare, fresare, filettare, secondo le necessità, e poi levarsi i trucioli metallici nella stazione di lavaggio e tornare alla stazione di carico/scarico. Quando il cestone in riempimento era pieno, veniva prelevato dal buffer, quello in svuotamento divenuto vuoto era dsiponibile come un nuovo cestone in riempimento. Notare bene: gli attrezzi, una dozzina, erano diversi e la linea, appunto “flessibile”, permetteva la produzione contemporaneamente di particolari diversi. Le macchime a controllo numerico, il robot di lavaggio ricevevano i "part-program" adeguati all'attrezzo, quindi al particolare in arrivo. Una linea flessibile era già stata fornita da Babau ad un altro cliente, che chiamiamo “TexWiller”. Ma del software di quella applicazione si è ricavato abbastanza poco: il processo di movimentazione sulla rulliera che avveniva modificando le mappe della memoria dei PLC, la comunicazione con i PLC, il monitoraggio e l'invio del part program ai controlli numerici, ma di completamente nuovo vi era uno scheduler, cioè un programma che indcava al sistema “quale attrezzo assegnare a quale macchina” in base a tutta una certa serie di regole. Sottostava a tutto ciò una parte di gestione di dati abbastanza complessa, assolutamente assente nel progetto “TexWiller”. Inoltre la linea da gestire era molto “cresciuta” ed anche altre funzionalità erano modificate e migliorate.

Team: Facevano parte del team software un “capo progetto” di Babau, un dipendente di Babau, che chiameremo “piemonteis”, entrambi avevano lavorato sul progetto “TexWiller”; un ex borsita del politecnico poi assunto da Babau dedicato soprattutto a studiare le prestazione dello scheduler. Un

gruppo di persone di una software house: Mario, un “analista” che di fatto diceva al “capo progetto” cosa si deve fare; Guido, molto bravo soprattutto ad affrontare i temi ad impatto sistemistico, Roberto che sarei io, che oltre a sviluppare un bel po' di codice, era presente negli USA durante l'avviamento del sistema, a gestire la fase di start-up, con modifiche e correzione al volo di bug nella sua parte ed in quelle dei colleghi; altri programmatori che avevano sviluppato varie parti. Poi c'era Maurizio, quello che ci aveva fatto fare il test, che era di un'altra software house, e si era occupato della parte più a basso livello, cioè nei driver di comunicazione con i PLC e con i controlli numerici: rispetto a TexWiller il volume di tali dati era notevolmente cresciuto ed anche le versioni del sistema operativo abbastanza cambiate.

Altri dettagli: Si trattava del progetto più grandioso a parità di risorse tecnologiche a cui abbia mai partecipato. Il PDP 11 era una macchina a 16 bit. Le unità a disco, RL02, erano da 10Mega l'una. Ricodo che quando dovetti portarne una dall'Italia, dove io ed i colleghi avevamo scritto l'ultima release, negli USA per installare, ho dovuto usare lil borsone che adopervo abitualmente per la piscina: oggi 32giga stanno nel taschino. Ovviamente avevamo sviluppato anche un sistema di monitoraggio della linea, un sistema di log e avevamo fatto anche una implementazione “ad hoc” di quello che oggi sono i dischi RAID, cioè avevamo quadruplicato il database su due unità a disco diverse, in modo che in caso di crash di sistema ci fosse almeno una copia del DataBase non in aggiornamento. Per quanto riguarda il log, era del solito tipo. Quando i programmi applicativi riscontravano un evento degno di nota, che poteva essere una segnalazione di errore o una semplice informazione, inviavano un messaggio ad un processo che registrava l'evento con data e ora su un file ed eventualemente inviava il messaggio su una stampante. Putroppo il capo progetto ed il cliente avevano esagerato nel decidere quali messaggi mandare sulla stampante, per cui questa scriveva con ritmo metronomico pagine e pagine che nessuno mai guardava. Il rumore della stampante era una musica “ambient” di sottofondo della sala. Quando il ritmo cambiava diventando frenetico oppure la stampante taceva, quello era il segnale che era successo qualcosa di anomalo. Il responsabile se ne accorgeva e iniziava a verificare. Se avessero messo un cicalino avrebbero

ottenuto lo stesso effetto,risparmiando carta.

Illustrazione 2: Terminali VT100 nella sala controllo

Tutta questa spiegazione serve per introdurre sia al baco che sto per descrivere sia per quello successivo. Non ci siamo ancora arrivati. Faccio una piccola premessa. Io sono sempre stato criticato per tantissimi motivi, tra cui quello grave di trovare facilmente significati agli acronimi più realisti di quello che volevano dire nell'intenzione dell'autore e nel contempo la capacità di creare acronimi con significato. Giuro che invece il nome di un programma che ho fatto, non l'ho scelto io: LSD che nell'ottica del “capo progetto” Babau, voleva dire Line Status Display, perchè anche per TexWiller il programma che aveva queste funzionalità si chiamava così. Un programma allucinante! Su uno schermo di un VT100 (bianco/nero 80 caratteri per riga, per 24 righe, mica un terminale grafico) c'era una piantina dell'impianto, con il tornio le quattro macchine utensili a quattro assi, la stazione di lavaggio la stazione di carico, le postazioni della rulliera, e giocando sul blink, bold, half-tone e reverse, l'utente poteva vedere dove si trovavano gli attrezzi, lo stato delle macchine se in allarme o inattive o in esecuzione e se stavano lavorando si leggeva la percentuale del programma eseguito. Il tutto venviva rinfrescato a tempi fissi da uno a nove secondi (per impostarlo bastava battere il tasto della cifra). Nella illustrazione 2 si vede LSD attivo sul terminale centrale. I gestori del sistema, due tecnici americani che sia alternavano nei due turni, tenevano questo programma sempre attivo su un terminale. Dalle finstre, vedevano dall'altro il sistema fisico, e con questi due strumenti controllavano tutto come il comandante dal ponte di coperta di una nave.

Bug: Una volta mi accorsi (o forse si accorse il tecnico americano) che LSD aveva smesso di riaggornare i dati. Intanto la stampante taceva ed i sistemi di controllo della linea a basso livello andarono in allarme. Il PDP11 aveva un programma chiamato RMD che era l'equivalente del “gestore delle attività” di Windows: faceva vedere tutti i processi con le loro priorità e occupazione di memoria. Anche questo aggiornava ciclicamente i dati, ma in quella situazione non li aggiornava più e non si poteva più uscire. Lo scheduler, che girava ad intervalli definiti, non partiva. Invece se qualcuno era in editor, o eseguiva

programmi per scrivere sulla base dati, poteva continuare benissimo il suo lavoro, senza accorsi che il sistema era in quella situazione anomala. Insomma, tutto quello che era legato al clock del sitema rimaneva bloccato, il resto funzionava. Dopo un po' tutto riprendeva a viviere e l'orologio del sistema rimaneva indietro di non ricordo più quanti minuti, ma comunque sempre di un intervallo di tempo ben preciso. Questa situazione si ripeteva “ogni tanto”. Solitamente quanto un programma utente cerca di accedere a certe aree di sistema, va in “crash” il programma stesso: cessa la sua esecuzione, ma non fa danni altrove. Qui invece no. Così addentro nel sistema ci andava solo il software di Maurizio, che aveva fatto delle modifiche ai driver per comunicare con i PLC e i CNC. Sebbene avesse un cognome di origine siciliana, quelle erano solo le sue origini remote. Maurizio era toscano di nascita e cultura, traferito a Milano e di milanese aveva preso un po l'accento, ma non il frasario. Le imprecazioni che sparò in fase di debug potrebbero essere l'oggetto di una tesi di laurea in dialettologia sulla contaminazione delle parlate e delle tradizioni locali.

Sta di fatto che Maurizio scovò e corresse il magico boomerang. Però dovette farsi un viaggio negli States. Io ero già lì. In quel week end avrei potuto combinare con altri di andare a vedere le cascate del Niagara. Invece dovemmo andare all'areoporto a prendere Maurizio. In seguito non riuscimmo più a combinare e io non ho mai visto le Cascate del Niagara.

Arma a doppio taglio

L'argomento di questo racconto è l'unico software bug a cui ho assistito che, se non vi fossero stati controlli ulteriori sugli strumenti fisici che il software controllava, avrebbe potuto creare danni. Non alle persone, ma alle cose. Non sto a descrivere il contesto perchè è esattamente lo stesso del racconto precedente. Spero che nessun lettore abbia deciso di fare come faccio abitualmente io quando leggo, cioè di salterellare tra i capitoli, soprattutto se sto leggendo romanzi gialli. Nel caso lo avesse fatto, lo prego leggersi il contesto operativo dal precedente capitolo.

Ricordo che tra i componenti del team, il capo progetto ed il “piemonteis” era reduci da un progetto che chiamiamo “TexWiller” da cui Babau sperava di recuperare parte del software. In realtà il recupero era abbastanza scarso, ma in compenso la loro forma mentis era legata a quel progetto. Quando c'era qualche discussione su come realizzare qualcosa, il capo progetto esordiva con “ricordo che in TexWiller si faceva in questo modo....” e così i due tendevano a sottovalutare tutte le altre implicazioni che la parte completamente nuova e molto considerevole, portava con se. Altro inciso. Nella mia tesi di laurea citavo Per Brinch Hansen, uno dei massimi guru dell'informatica degli anni '70. I suoi studi a quei tempi erano orientati all'archituttura dei programmi concorrenti: un architettura che descrive il nostro caso, cioe un sistema composto da tanti “programmi” che sono eseguiti contemporanemente e si scambiano dati. Nella mia tesi di laurea giustificavo l'architettura della mia applicazione, (un sitema per valutare le ipotesi di interpretazione in un riconoscitore del linguaggio parlato) rifacendomi a Per Brinch Hansen. Egli sosteneva che non doveva esserci un'area dati comuni da cui tutti i programmi pescano e versano dati, ma ogni programma dovesse avere la sua coda di input, da cui prendere i messaggi e il suo output doveva finire nella coda di input di altri programi.

Questa architettura proposta è qui descritta rozzamente per motivi di spazio, Per Brinch Hansen mi perdoni. Nella tesi l'avevo spiegata meglio. Quando iniziai a lavorare mi imbattei in un progetto dove invece i processi concorrenti si scambiavano dati in un area comune. E' pur vero che a basso livello le code si implementano con aree di memoria, ma questo approccio mi pareva grezzo e disordinato. Anche nel progetto in Babau si seguiva lo stesso approccio, cioè grossa area comune dove tutti scrivono e leggono dati, seppur con un semaforo per accedere ai più critici. Ah, la teoria! In questo progetto l'area comune si chiamava TSKCOM, particolare irrilevante per l'informatica, ma utile per procedere nel racconto. Quest'area di memoria, che conteneva tra l'altro tutte le posizioni degli attrezzi sulla rulliera, lo stato delle macchine utensili e via discorrendo, veniva salvata ogni interevallo di tempo fisso, ma breve, su disco, per fare si' che alla prossima ripartenza del sistema la situazione fosse analoga alla situazione reale dell'impianto, a meno di spostamenti effettuati in locale a computer spento, piuttosto improbabili. Inoltre erano state sviluppate delle “utility” che permettevano di leggere e modificare dei dati al suo interno. All'accensione del computer, dopo la normale procedura di bootstrap, veniva attivata una procedura di avviamento del nostro sistema in cui comaparivano sulla consolle delle domande molto strane, a proposito delle quali sia Guido sia io esprimevamo al capo progetto le nostre perplessità. Lui rispondeva: “...ma in TexWiller ...” L'utilizzatore americano del sistema, si era fatto un suo manuale utente con le spiegazioni in chiaro di cosa volessero effettivamente dire queste domande e quindi cosa occorresse rispondere. Una di queste domande era: “Would you like to start from a inizialized copy of TSKCOM ?” Capisco che in una fase di test off-line un programmatore volesse “ripulire” tutti i dati e partire da una memoria pulita. Nel sistema di sviluppo questa era una opzione usata spesso in fase di test, ma nel sistema finale, on-line, quando di dati della memoria dovrebbero rispecchiare i dati dell'impianto, dare questa possibilità all'utente, che in teoria non doveva neppure sapere cosa significasse la parola TSKCOM, era un'istigazione al suicidio. Ovviamente la risposta da dare era NO, e così facendo il sistema si sarebbe caricato nella memoria la copia che

era stata salvata su disco poco prima di attivare la procedura di spegnimento del sistema. Eventuali differenze sarebbero state causate da spostamenti fatti offline, quindi molto rari e ricostruibili con apposite funzioni. Un giorno era presente nella sala controllo dell'impianto un altro signore del Babau, un italiano stabilitosi in America, che faceva non so bene cosa, se il commerciale Babau sul suolo americano o coordinatore tecnico, vassapere. Un tipo tarchiato, con la faccia butterata che cercava di coprire con la barba che gli cresceva rada e lanugginosa, peggiorando ancora il suo aspetto. insomma piuttosto brutto, ma simpatico. Noi gli stavamo illustrando il sistema, che proprio in quel momento si stava ri-avviando. Sulla consolle comparve la domanda: “Are you starting after a normal shutdown ?” Tralascio cosa in realtà nascondeva questa domanda. Sta di fatto che anche se il sistema fosse stato chiuso con tutti i programmi applicativi in errore, o perchè un addetto era stramazzato per un colpo apoplettico, occorreva comunque rispondere “Y” (Yes) “Posso fare io?” chiese il bell'uomo. “Si” rispse il capo progetto. Schiacciò la Y contento di aver partecipato al risveglio del gigante dormiente. Immedatamente la consolle propose: “Would you like to start from a inizialized copy of TSKCOM ?” Ormai preso dal suo nuovo ruolo, con una zampata felina, precedendo ogni nostro tentativo di bloccarlo, il bell'uomo permette un'altra volta la “Y”. “No!!” esclamai. Il sistema ripartì come se non ci fosse nulla sulla linea, invece c'era un decina di attrezzi che attendevano di essere instradati nelle opportune macchine. LSD feceva vedere il deserto. In quel momento provai una sensazione sgradevolissima: l'idea di aver risolto il problema ed immediatamente dopo la certezza che quell'idea non era la via

corretta. Pensai: bel problema, però abbiamo una copia di TSKCOM salvata su disco, ma qualche microsecondo dopo mi resi conto che, essendosi avviato il sistema, quella copia era gia stata ricoperta con quella vuota! Mi accasciai su una sedia con le mani tra i capelli che allora erano molti, folti e abbastanza lunghi! In quel momento il “piemonteis” si allontanò dal gruppo. Tornò cinque minuti dopo con un foglietto di carta su cui aveva segnato dove si trovavano gli attrezzi sulla linea. Confesso la mia colpa: fui leggermente risentito dal suo atteggiamento “ecco, mentre tutti sono lì che si lamentano del danno, io invece, col mio senso pratico, sono sceso (infatti la sala computer era come il ponte di comando della nave rispetto all'impianto) e ho fatto il giro della linea a prendere la posizione di tutti gli attrezzi.” Il risentimento che provai per il suo ostentato senso pratico, mi impedì di capire subito cosa sarebbe successo da lì a poco e quindi di fermare ogni sua ulteriore azione che emergesse dal suo senso pratico. Lui pensava ancora nei termini “in TexWiller si faceva così” e non gli sarebbe mai venuto in mente che l'ordine con cui avrebbe inserito il codice degli attrezzi era importante. Infatti, non sto qui ad addentrarmi nei dettagli che non ricordo e tedierebbero il lettore, in qualche modo la tabella degli attrezzi presenti nella memoria era anche usata come indice per accedere ad un file in cui vi erano parecchie informazioni di dettaglio e tra queste anche i part-program necessari per la lavorazione dei pezzi montati. La logica per ricostruire TSKCOM sarebbe stata quella di partire dal file, ricostruire la tabella degli attrezzi in TSKCOM rispettando l'ordine sul file, poi “posizionare” in TSKCOM gli attrezzi al posto giusto sulla linea, con le opportune “utilities”. Invece il “piemonteis” si sedette al terminale e, con le apposite “utilities” per valorizzare i dati in TSKCOM inserì codici e posizioni degli attrezzi, nell'ordine in cui le aveva scritte sul suo foglietto, fregandosene dell'ordine sul file. Il risultato fu che il sistema fece muovere un attrezzo verso un controllo numerico per eseguire un “part-program” che non c'entrava nulla con i particolari montati su quell'attrezzo, anzi probabilmente avrebbe cercato di trapanare l'attrezzo stesso. Abbiamo capito come si sarebbe dovuto fare per ricostruire l'area TSKCOM e abbiamo verificato che le macchine a controllo numerico avevano dei sistemi di allarme funzionanti. Sarebbe stato meglio analizzare questa procedura di recovery ed i meccanismi di allarme sulle macchine utensili in un altro modo.

Lo scaravoltone

Piattaforma: VAX-11, collegato ad un sistema di visione e a un PLC. Ambiente di svilupppo: Fotran 77 su VMS Contesto operativo: Factory automation Svolgimento del fatto: 1990 Torino e Food Vally (Italia).

Quello è stato il progetto migliore della mia vita. Penso di aver fatto un bel lavoro, il commerciale mi ha inviato una lettera di congratulazioni perchè il cliente si è veramente trovato bene. Per i cavilli del regolamento interno della azienda di cui ero dipendente relativamente agli incentivi sui progetti, per quel progetto non presi nessun incentivo. Era anche uno dei periodi più belli della mia vita. Il mio capo di allora, Franco, era una persona che stimavo moltissimo perchè aveva sia una notevole competenza tecnica, sia una buona capacità relazionale. Seppi che prima di essere mio collega e responsabile nella software-house, aveva iniziato la carriera in XXXX ed era poi ato in YYYYY perchè si sentiva "più motivato a fare arrivare i treni in orario piuttosto che lanciare bombe con più efficacia". Il suo atteggiamento etico emergeva anche in ogni atteggiamento che aveva sul lavoro. In quel periodo io stavo per sposarmi. Franco si occupava dei corsi di preparazione al matrimonio nella diocesi di Torino, ed era contento del fatto che io mi accingessi a tale o. La città in cui dovevamo installare il sitema e provarlo nello stabilimento poco distante, era una bella città. Era possibile anche per noi fornitori accedere allo spaccio aziendale, comprando generi alimentari a prezzi scontatissimi. Inoltre in quella zona c'erano parecchi edifici per la stagionatura di un tipo di formaggio particolarmente apprezzato e si potevano fare acquisti convenienti. Si tornava a casa con i viveri.

Il cliente era desideroso che il sistema funzionasse. Può sembrare strano, ma questa circostanza, nella mia vita mi è capitata abbastanza raramente. Su questo tema ci tornerò parlando del prossimo baco, ma se il cliente desidera che il sistema funzioni, tende a metterti nelle condizioni ottimali perchè tu lavori, e questo è positivo. Si trattava di una azienda alimentare che produceva prodotti da forno. Il forno era un tunnel dentro al quale scorreva a mo' di tapis roullant una griglia. I prodotti stavano su questa griglia ed attraversavano lentamente il forno. Quando uscivano dal forno, percorrevano ancora qualche metro sulla griglia. Poi cadevano su un altro tapis roullant che li portava, in una posizione diversa da quella in cui erano stati nel forno, in un area abbastanza lontana. Qui delle persone svolgevano un lavoro tutto sommato noioso, (infatti avevano turni abbastanza brevi) ma importantissimo. Scartavano i prodotti da forno evidentemente bruciati e prendevano con mani guantate i prodotti da forno “buoni” e li mettavano su delle canaline che il portavano ad una macchina confezionatrice. Ma, oltre al fatto che quella mansione non era tra le più ambite, in quel punto i prodotti che uscivano dal forno erano girati in modo tale che i difetti non si vedevano molto bene. Inoltre una persona poteva fare quel lavoro solo ad una certa distanza dal forno stesso, per non cuocere anche lei, e questo imponeva una linea decisamente lunga che occupava molto spazio. Automatizzare il processo era abbastanza complicato, soprattutto per l'irregolarità della forma dei prodotti che uscivano dal forno. Soluzione: Sistema di visione –> VAX-11– >“Zampa di ragno” gestita da un PLC. Il Sistema di visione, con le telecamere a poca distanza dall'uscita del forno, elaborava le immagini dei prodotti decidendo se erano da prendere oppure no (ovviamente era quasi sempre sì, sennò la ditta avrebbe chiuso) e le loro posizioni. La “Zampa del ragno” aveva otto ventose che consentivano di prendere otto unità di prodotto alla volta e le metteva su di una canalina che alimentava una macchina confezionatrice. Siccome le unità di prodotto avevano forme irregolari, la “Zampa del ragno” doveva avere in input dei valori di spostamento per cogliere il prodotto correttamente. Il calcolo di questo spostamento ottenuto a partire dai dati ricevuti dal sistema di visione, era effettuato dal VAX-11 e da questo inviato al PLC della “Zampa”. Ovviamente il VAX-11 aveva anche un sistema per registrare i dati del sistema di visione per poter fare girare più versioni dell'algoritmo e vederne i diversi esiti. C'era anche

un sistema che, nei limiti dei terminali, di allora “graficava” la situazione. Il “tapis roullant” ci inviava anche un valore numerico su 16 bit di “encoder” che corrispondeva alla coordinata Y dei dati del sistema di visione e del nostri valori che davamo alla “Zampa”. Inutile dire che la coordinata X era relativa al tapis roullant in larghezza. Quindi la coordinata Y andava da 0 a 65535 per poi ritornare a 0 dopo un “giro completo”. Ci eravamo accorti che i dati che ricevevamo in input erano troppo “distanziati”. Supponiamo ogni 5 secondi (a dire il vero non ricordo). Era una risoluzione troppo scarsa per fare dei buoni calcoli relativamente ai dati che ricevevamo dal sitema di visione. Allora decisi che la soluzione era quella di avere la coordinata Y valorizzata da due moduli software, schematizzati in questo modo: //modulo 1: input da encoder while(sitemaAttivo){ WaitForEvento(LettoNuovoDatoEncoder) EnterSemaphore() CoordY = ValoreEncoder; LeaveSemaphore() } //modulo di affinamento. Supponendo che Evento “LettoNuovoDatoEncoder” si verificasse ogni 5 secondi, e volendo affinarlo ad 1 secondo. Interger*32 tmpSu32bit while(sitemaAttivo){ Wait(1 secondo) EnterSemaphore() tmpSu32bit= CoordY ;

tmpSu32bit= tmpSu32bit+ deltaPrevisto; if ( tmpSu32bit < 65535) { CoordY= tmpSu32bit; else CoordY= tmpSu32bit – 65535; LeaveSemaphore() } In pratica, ogni secondo incrementavo il valore di un piccolo delta, poi il dato vero dell'encoder correggeva eventuali derive. Il problema era gestire il superamento del valore massimo rappresentabile con 16 bit, che avevo risolto in quel modo. L'analisi l'ho qui abbozzata in pseudo-C, ma allora di programmava in Fortran 77. Scrivemmo una prima versione del codice a Torino e lo portammo presso lo stabilimento del cliente. Nella fase iniziale, ricevevamo i dati dal sistema di visione, ma non eravamo collegati alla “Zampa”, analizzavamo solo il nostro software prevedendo come avrebbe reagito. Sembrava andare tutto abbastanza bene, ma sarebbe andato ancor meglio con qualche piccola modifica a qualche parametro. Faccio la modifica, bella ricompilazione e zac, il sistma sembra funzionare anche meglio sennonchè, ahi, accadde quello che il cliente chiamò “lo scaravoltone”. Per qualche ciclo fu come se, per in nostro sistema, le unità di prodotto in uscita dal forno fossero spappolate, la grafica presentava sgorbi assurdi, i valori per la zampa privi di logica, per poi riprendersi tutto pochi istanti dopo. Tutto procedeva bene, ma “ogni tanto” si verificava lo scaravoltone. Come di prammatica, provai da dare la colpa all'ultima modifica fatta, perchè prima “lo scaravoltone” non si era mai verificato. Ma analizzando bene, la causa non poteva essere quella (oggi non ricordo cosa fosse questa modifica). Ne conclusi che prima della modifica “lo scaravoltone” non si era ancora verificato, ma doveva già esistere “in potenza”. Avevo un senso di angoscia. Lo scaravoltone si verificava “ogni tanto” stava

anche diverse ore senza comparire. Era un susseguirsi di ipotesi e di loro negazioni. La soluzione mi venne in mente sotto la doccia. Dovetti aspettare la mattina successiva per verificarla. Ora spiego l'inghippo in dettaglio, ma una spiegazione così particolareggiata mi venne in mente solo dopo un po' di tempo. Il lettore accorto avrà capito che il problema era in quei moduli relativi alla coordinata Y, altrimenti non li avrei descritti. Ma come e perchè? Ricordo che il tutto era scritto in Fortran77, un'evoluzione del vecchio Fortran IV, ma che del vecchio linguaggio ereditava il fatto di essere posizionale. Spiego meglio per le giovani generazioni. Nel Fortran era importante anche In che colonna si scrivevano certe cose. Se il primo carattere era una “C” la riga non era una istruzione, ma un commento.(Ricordo la frase di cui non cito l'autore per decenza "Per fare una modifica ad un programma, basta mettere un C davanti ad uno statement!) Le colonne dalla 1 alla 5 potevano essere lasciate vuote oppure contenere un numero, che era la “label” dell'istruzione, ove servisse riferirla in altre parti del codice. La colonna 6 era abitualmente vuota, se conteneva un carattere, significava che la linea era una continuazione di quella precedente. L'istruzione vera e propria stava dalla colonna 7 alla 72. Le rimanenti colonne oltre la 72esima erano automaticamente considerate commenti. Avevo cercato di lavorare meglio che potevo. Il programma faceva uso di vari parametri numerici ma questi erano tutti valorizzati in un punto preciso. Nel codice non c'erano valori numerici, ma solo dei riferimenti a questi valori. Ovviamente se avessi dovuto cambiarne uno l'avrei cambiato in un punto solo e non sarei andato a cercare per tutto il codice. Unica eccezione fu il “massimo numero su 16 bit” un po' perchè non sarebbe mai cambiato, ma soprattutto perchè l'avevo usato solo in quel punto, e un po' perchè era una decisione presa all'ultimo momento. Va da se che nell'istruzione

CoordY= tmpSu32bit – 65535 il 65535 era finito a cavallo della 72esima colonna: era diventato 6553 ed il 5 era divento un commento. Se fosse stato solo così, sarebbe stato troppo facile. La Digital, ditta che produceva il VAX-11, bontà sua, intuendo che le colonne dalla 7 alla 72 erano un po' pochine per scrivre le istruzioni, soprattutto perchè con Fortran 77 si potevano usare variabili con nomi più lunghi di 6 caratteri, aveva deciso di permettere al compilatore di NON considerare commenti i caratteri oltre il 72, ma permettere che l'istruzione andasse fino alla colonna 132. Per fare ciò occorreva indicare un parametro nella riga di comando del compilatore. Il nostro sistemista aveva installato il Fortran77 mettendo questo parametro come default, cosicchè nella versione compilata a Torino il numero era veramente 65535 e all'inizio lo scaravoltone non si presentava, poichè la prima versione installata era stata compilata a Torino. Il sistemista che aveva installato il VAX-11 nello stabilimento non aveva fatto altrettanto. E' per questo che il problema emerse solo dopo una ricompilazione generale in loco, anche se la modifica al codice era da tutt'altra parte. Inoltre per fare un giro completo ava un bel po' di tempo. Se poi nel progetto ci fosse stata qualche altra riga a cavallo della colonna 72, che magari avesse generato un errore sintattico, che ne so, un THEN che diventava THE, allora mi sarebbe venuto qualche sospetto, ma nulla di tutto ciò. Ancora: non sempre il salto da 65535 a 0 era intercettato dal modulo di “affinamento”, talvolta veniva gestito dal modulo che legge il dato dall'encoder e quindi il problema, chè già capitava raramente, in quei casi non si verificava, ma restava in agguato.

Risolto questo problema il progetto, dal nostro punto di vista ebbe un lieto fine. Il prototipo funzionava. Invece il sistema non fu implementato perchè gli esperti della qualità della ditta che produceva questi oggetti commestibili, si accorsero che il prodotto da forno raffreddato lungo le linea lentamente e quello “aspirato” dalla zampa presso l'uscita dal forno avevano gusti diversi. Siccome i consumatori erano abituati ad un certo gusto, cambiare sarebbe stato un rischio.

Ti dico che in questo momento sto tacendo!

Piattaforma: VAX-11, collegamento a rete di PLC AllenBradley. Progammazione in Pascal Contesto operativo: Factory automation Svolgimento del fatto: 1992, Piemonte.

Ambiente di lavoro pessimo anche se ne ho incontrati due ancora peggiori. Il cliente era una grande multinazionale, abbastanza nota per la sua eticità, ma purtroppo le sedi italiane avevano ampia autonomia gestionale. Si trattava sempre di “automazione di un'area di uno stabilimento” ma le funzionalità richieste erano risibili rispetto al progetto di Babau. Qui i PLC avrebbero potuto fare tutto loro: in dieci anni circa la tecnologia era migliorata e le funzioni in questo sistema erano ridotte. Il responsabile della sede torinese decise di matterci anche un VAX-11, seguendo il noto ragionamento “perchè ci sono dei soldi nel budget e se non li spendiamo, poi ci taglieranno il budget del prossimo anno”. Però a questa logica, spendiamo i soldi anche per cose che non servono, altrimenti tagliano i budget, occorre aggiungere un attitudine tipicamente torinese: ma dobbiamo anche dimostrare che abbiamo risparmiato qualcosa, rispetto a quello che sarebbe stato normale spendere per fare ciò che abbiamo realizzato. Il fatto che la presenza del VAX-11 non fosse vitale, rendeva paradossalmente peggiore la situazione, perchè non focalizzava le energie del cliente a fare si che potessimo installare quanto ci avevano ordinato. Più tardi cosegnavamo, più tardi avrebbero pagato. La società aveva parecchie sedi in Italia: a Torino c'era "la testa" mentre lo stabilimento di produzione presso cui si doveva installare era ad una ottantina di chilometri circa dalla sede torinese.

Uno dei tencnici che lavoravano sul PLC era dipendente di questa multunazionale presso la sede di Torino. Era prossimo alla pensione ed ogni giorno di presenza nello stabilimento fuori città era un giorno di trasferta in più non solo sulla busta paga, ma che gli avrebbe anche aumentato di qualche lira la pensione futura. Il direttore, il nostro committente, era fatto esattamente al contrario di quello che Stephen Covey dice a proposito del numero di orecchie e bocche che ci sono abitualmente in una testa umana. Stephen Covey sostiene che le orecchie siano due e la bocca sia una. Il motivo? Perchè occorre ascoltare almeno il doppio di quando si parli. Invece questo capo parlava e basta. I suoi subalterni, le persone con cui io avevo direttamente a che fare, erano dei grandi pescatori di trote di Avigliana. Non che il sabato e la domenica andassero ai laghi di Avigliana con la canna da pesca: è una metafora che spiega bene il loro atteggiamento. Si racconta che anticamente ad Avigliana ci fosse una comunità di frati dal comportamento non proprio esemplare. Quand'era quaresima avrebbero dovuto astenersi dalle carni. Allora essi pigliavano delle cotolette, le mettevano all'amo, le gettavano nel lago e poi tirandole fuori esclamavano “Ma che bella trota!” Insomma, erano esperti a fare i cavoli loro rispettando formalmente le regole. Come esempio di pesca, uno dei dipendenti della sede torinese, non so per quale ragione, doveva recarsi in una sede se. Il regolamento permetteva di usare l'auto solo se ci fosse stato del materiale superiore ad un certo volume o peso prefissato. Costui si portò con se una carica di dossier di utilità scarsa o nulla, per poter usare l'auto. A parte questo episodio emblematico, un capo eccessivamente assertivo ed un ambiente con regole eccessivamente rigide, genera dei pescatori di trote di Avigliana. C'era in questa ditta una persona simpatica, uno dello stabilimento produttivo. Il mercoledì lui non c'era. Era un cassa integrazione. Il sabato invece doveva andare in azienda a fare straordinario. Io ero abbastanza stressato tra la mia ditta che voleva chiudere il progetto, ovviamente, ed anch'io ci tenevo a mettere la parola fine, ed il cliente, o meglio il personale del cliente, che invece non aveva nessun interesse a finire. Ora va di moda parlare di aziende centrate sul cliente (vedi Peter Drucker) ma se

il personale del cliente non è “allineato” sugli stessi obiettivi del cliente-azienda, è difficile essere centrati sul cliente. Il fatto che all'interno della stessa organizzazione ci siano forze contrastanti, è una cosa nota ai commerciali, i quali cercano di individuare i “decisori che contano”. Già, ma una volta partito il progetto? Nel PMBoK, quinta edizione, vi è un'intero capitolo, il tredicensimo, dedicato alla gestione degli stakeholder. Ma allora eravamo nel 1992, dovevano are ancora vent'anni prima che uscisse la quinta edizione.

In una delle tante variazioni all'ordine si decise di fare una certa attività. La multinazionale, nella sua sede “estera”, aveva sviluppato per il VAX-11 un sistema di Log, con report per la manutenzione preventiva e sitema di allertamento dei manutentori. Si era deciso di usare anche sul nostro VAX-11 questo sistema. L'installazione fu banale, bastava seguire le istruzioni fornite. Il problema era configurarlo. Ovviamente questo doveva essere fatto in collaborazione con il cliente. Da parte mia avevo individuato nei programmi applicativi alcuni eventi che mi pareva utile finissero in input a questo sistema di Log. Nel codice bastava fare una chiamata ad una funzione dalla loro libreria, con l'idendificativo che veniva definito per l'evento ed eventuali parametri. Avevo fatto un elenco di questi eventi e mi sarebbe piaciuto discuterne con il “cliente” torinese, sapere come raggrupparli per sottoimpianto, per tipologia, per quale fosse sufficiente la registrazione su file, per quale fosse necessario anche un messaggio su stampante, quale dovesse generare una chiamata ai manutentori. Non avevano mai tempo. Comunque batti e ribatti, l'unica stampante disponibile per fare andare certi messagi sul log era la consolle del sistema stessa. Ok, i messaggi erano abbastanza pochi e quelli da mandare in stampa piuttosto rari. La cosa poteva anche andare. Anzi sicome erarno eventi rari, per verificare il funzionamento feci un programmino che li simulava. Volevo dimostrare “Il sistema da parte nostra è predisposto, quando avrete intenzione di configurare, la cosa è fattibile”. Feci girare il tutto e : magia! Sulla consolle comparve: “Data – Ora - Messaggio previsto con parametri previsiti” ma quasi immediatamente dopo: “Data – Ora - Allarme: la stampante (identificativo di questa stessa stampante) è spenta o non funzionante. Il messaggio precedente non è stato stampato.

L'evento questa volta era riproducibilissimo. Il clima era teso. Ovviamente era colpa mia. Riuscii a capire il problema perchè nel disco che conteneva il kit d'installazione erano rimasti, penso per sbaglio, dei sorgenti del software sviluppato dalla “multinazionale all'estero”. Sono riuscito a capire cosa avevano ideato. Tanto di cappello a costoro. Lo spiegai in modo più neutro possibile, con un notevole sforzo riuscii a non fare ironia. Non so poi come abbiano deciso di proseguire. Oggi al posto della sede degli uffici a Torino di quella multinazionale, c'è un centro commerciale. Gli “esteri” per scrive un messaggio di log su una stampante, non usavano l'istruzione di scrittura, ma di lettura, con prompt e timeout. Troppo difficile? Cos'è il prompt: avete presente quando si va nelle videate DOS (schermo tutto nero solo a caratteri come erano i vecchi terminali una volta?) si iniza a scrivere su una riga in cui c'è il path dove ci sitrova su disco, seguito da un > . Ecco quello è il “prompt”: un insieme di caratteri che il sistema emette per indicare che è pronto a leggere. Il nostro sistema di log come “prompt” ci metteva tutto il messaggio che doveva scrivere, in più ci aggiungeva una sequenza di caratteri non visibili, ma che la stampante avrebbe dovuto interpretare come “richiesta di stato” e la risposta che la stampante dava alla "richiesta di stato" costituiva la lettura. Inoltre era stato definito anche un time-out cioè un tempo limite entro cui la lettura avrebbe dovuto essere fatta. Se scattava il time-out evidentemente la stampante non era funzionante ed allora partiva la segnalazione della situazione anomala sulla consolle del sistema, che ovviamente, nella testa degli “esteri” non era la stessa stampante di Log. Ma perchè scattava il time-out ? Perchè siamo a Torino e siamo in una azienda meritocratica. Loro dicono: abbiamo fatto un sistema che non serve a nulla, altrimenti ci avrebbero fatto dei tagli al budget del prossimo anno, ma nel farlo, per essere meritevoli, abbiamo dimostrato che abbiamo speso di meno di quanto sarebbe costato se l'avessimo fatto “normalmente”: invece di prendere stampanti o consolle di sistema della “Digital” ne abbiamo scelte di una marca che costava meno. Guarda caso, queste stampanti non interpretavano le sequenze di caratteri di controllo previste per le stampanti e consolle Digital, cosicchè scattava il time-out ed il sistema interpretava l'evento come "stampante spenta".

Dubbi sulla rotondità della terra.

Piattaforma: PC Windows. Progammazione in Visual Studio – C/C++ MFC Contesto operativo: Automotive Svolgimento del fatto: 2004, Piemonte.

Lavorai per circa dieci anni in un contesto molto interessante. Si facevano prototipi di sistemi di ausilio alla guida (ADAS). Se si fosse proceduto con più determinazione saremmo arrivati da tempo all' auto a guida automatica.

Riassumo brevemente la struttura "tipica" che nel corso dei dieci anni di applicazioni, ovviamente mutava nei particolari specifici ed evolveva nelle tecnologie. Il PC acquisiva tutta una serie di dati: dati relativi al veicolo stesso (velocità, imbardata, marcia, freni...), dati da radar, dati da centraline che “guardano” linee di separazione tra le corsie, telecamere, dati proveneienti dall'infrastruttura stradale, o da altri vericoli e chi più ne ha più ne metta. Il tutto nello shacker.... per realizzare particolari funzioni che in qualche modo “alleggerivano” il lavoro del guidatore. Tra questi dati che entravano nello shaker, vi erano anche i dati del sistema di navigazione e della cartografia digitalizzata. In base al percorso impostato e alla localizzazione con GPS, si teneva conto anche della tipologia di strada su cui si trovava il veicolo, dei prossimi incroci, prossime curve ed altre informazioni da aggiungere a quelle ottenute con altri sensori. Il sistema di navigazione e la cartografia digitale forniscono le coordinate geografiche in termini di latitudine e longitudine. Per i nostri calcoli serve averle su in piano, in metri, in coordinate cartesiane aventi come origine il veicolo stesso. I aggi logici erano due. Coordinate in metri nel piano cartesiano

avente come origine il punto in cui l'equatore incontra il meridiano di Greenwech e poi traslare quel piano in modo che l'origine degli assi fosse il veicolo stesso. Siccome i meridiani terrestri sono uguali fra loro, trasformare la latitudine in metri non era complicato, bastava moltiplicare per certe costanti. Invece i paralleli cambiano con la latitudine. Quindi la trasformazione della longitudine in metri dipendeva dalla latitudine. Doveva essere fatta in due i: dalla latitudine si trovavano le costanti, e poi si moltiplicava la longitudine per tali costanti.

Il baco di cui sto narrando era ralativo ad una “sottofamiglia” di applicazioni che avevano come dati cruciali per ulteriori ragionamenti, i raggi di curvatura delle prossime curve che il veicolo avrebbe incontrato, ovviamente se avesse seguito il percorso che aveva impostato sul sistema di navigazione. Conosere i raggi di curvatura delle prossime curve e la loro distanza dal veicolo, serviva a varie cose: dall'ottimizzare il "lavoro" del cambio automatico, all'avvertire il guidatore che avrebbe dovuto rallentare per prendere la curva ad una velocità confortevole, fino al Cruise Control Adattativo realizzato non solo in base ai veicoli che precedono, identificati da un radar, ma anche dalla velocità ottimale per entrare nelle prossime curve.

C'era una curva particolare ben identificata in un certo punto della periferia di Torino, per la quale ò ipotizzavamo che l'avvertimento sarebbe scattato se la si fosse presa sopra i 45 Km/h . Ciò non avveniva. Anzi, dai dati che si potevano vedere run-time sullo schermo del PC, pareva che la velocità rischiosa per quel raggio di curvatura fosse oltre gli 80 Km/h. Col cavolo! Agli 80Km/h ci sarebbe stato un bel rischio. La cosa era ancor più strana se si considerava il fatto che nello stesso percorso di prova, c'era un'altra curva abbastanza stretta ed il sistema segnalava l'avvertimento forse anche in modo troppo severo. Il nostro tool permetteva di registrare i dati e di analizzarli in laboratorio e qui, facendo ri-girare il percorso di prova, o almeno la parte del percorso prossima alla curva accadeva il miracolo: la curva diventava degna di allarme ai 45-50 Km/h come previsto. Quindi non si poteva dare la colpa né ai dati di input della

cartografia, né all'algoritmo di calcolo della curvatura, ma allora perchè avvicinandosi in quel luogo i risultati erano diversi? Ci misi un po' a risolvere il dilemma. Era stata una iper-ottimizzazione. Abbiamo visto che la trasformazione in metri dal punto 0 della longitudine richiedeva due i di calcolo. Ipotizzando che il nostro guidatore si muovesse esattamente lungo la linea dei meridiani, alla velocità massima consentita e, visto che sarebbe stato improbabile che alla guida ci fosse stato un senatore a vita, dopo quattro ore avrebbe dovuto fare una sosta idraulica. Quindi al massimo, ma un massimo irraggiungibile in un percorso normale, non ci si sarebbe spostati più di 520 Km di latitudine. Si poteva così evitare di ripetere ogni volta il primo o di calcolo per la trasformazione della longitudine. Si usa la prima latitudine che ci fornisce il GPS, si calcola la prima costante e si usa sempre quella. Peccato che il ricevitore del GPS ci mettesse “un po'” a darci i dati giusti, cosicchè la costante era calcolata come se ci trovassimo all'equatore. Perchè proprio quella curva lì? Evidentemente era orientata in modo che tale errore la “allargasse”, mentre altre curve venivano ristrette. E perchè in laboratorio il fenomeno non si ripeteva? Ovviamente se uno avesse registrato i dati di tutto il percorso di prova, dall'avviamento del sistema al suo spegnimento, compreso il tempo di attesa davanti al gabiotto del sorvegliante della ditta, ci sarebbero stati file enormi, pieni di dati inutili. Il programma aveva un comando per attivare e disattivare la registrazione. La registrazione partiva quindi quando i dati del ricevitore GPS erano già buoni ed il bug in laboratorio non si riproduceva.

Comunque questa applicazione permise di utilizzare un prototipo con un Cruise Control Adattativo in base alla curvatura della strada in un percorso autostradale Torino-Savona-Genova-Alessandria.

Manager scansati e lasciami lavorare

Nelle rappresentazioni di scenette comiche, quando si vuole evocare il personaggio dell'imbonitore si segue quasi sempre un certo clichè. L'imbonitore esordisce con “Signore e signori, siamo venuti su questa pubblica piazza per presentarvi ....” ed elencando le caratteristiche del prodotto presentato, per creare un cambio di intonazione della voce e quindi ri-attirare l'attenzione, si rivolge ad un inesistente ragazzino, tra i monelli che tipicamente gironzolano per le pubbliche piazze, con “Ragazzo, scansati e lasciami lavorare!”.

“Manager, scansati e lasciami lavorare!” Senza dirlo ad alta voce, ma quante volte l'ho escamato nella mia mente! Quante volte, durante certe prove, verso la fine del progetto, alle persone che si ingegnavano a fare, debuggare, correggere, editare, ricompilare, provare... se ne aggiunge una che si agita e freme, esulta e geme, ma non aggiunge nulla al lavoro degli altri. Quante volte mi sono domandato che gusto provassero le aziende, sempre attente ai costi, almeno in linea teorica, ad aggiungere una persona in più, solitamente la più pagata, che normalmente non da alcun contributo positivo al lavoro altrui, anzi, più frequentemente ha un impatto negativo, nel creare pressioni che generano tensioni e fanno diminuire la produttività. Quante volte ho provato un intimo disprezzo per i fantasmi da riunione. Tutto questo finchè ho avuto l'opportunità di vedere la scena da una prospettiva diversa.

Cio è accaduto quando è stato proposto a me un ruolo simile. Ho sentito un brivido gelarmi nella schiena. Ho sentito un profondo senso di impotenza nel coprire un ruolo in cui ero responsabile di cose in cui io non potevo metterci le mani, ma dipendevo dall'operato degli altri. Mi sono sentito come un ostaggio. Ho capito anche quel che spingeva un manager a fare una cosa che avevo sempre considerato come offensiva.

Qual è la cose più offensiva che mi sono sentito dire in circa quarant'anni di lavoro? “Grazie.” Mi spiego meglio. Non è che nessuno mi abbia mai insultato, anzi, per alcuni insultare i colleghi era quasi un modo per affermare la propria importanza aziendale. Nemmeno sono insensibile ai complimenti, anzi, “Hai avuto una buona idea” è una frase che mi ha sempre riempito di orgoglio. Perchè “grazie” mi offende? Il motivo per cui io faccio una cosa, non dico bene, ma al meglio che posso, è perchè quello è il mio lavoro: lo faccio per me, lo faccio nell'intento di fare qualcosa di valido per qualche utilizzatore. Dicendomi “grazie” il manager in qualche modo mi defrauda della proprietà del mio lavoro: dice “questo lavoro è mio, tu l'hai fatto per me”. Ma nel momento in cui mi sono sentito nei panni del “manager-ostaggio” ho capito cosa può are per la sua mente e perchè ringrazi. Ora mi domando, perchè mai molte aziende sono disposte a pagare stipendi anche alti, a project-manager intesi come “amministratore delegato del progetto” e non seguono quello che il PMBoK dice del project manager? Non è il caso di seguire autori “innovativi” come Niels Pfläging, basta seguire il PMBoK edizione V. In quel colloquio, dove mi fu offerto un ruolo simile, i miei intervistatori capirono benissimo, dal mio imbarazzo, che quel ruolo non avrebbe fatto per me. Trovai un altro posto, ovviamente molto meno pagato, da tecnico. Ma qui (omissis....) non posso dilungarmi per ovvie ragioni. Prevedo che ci sarà un’esplosione enorme … l'ho già sentita dire questa frase... sì, era di Italo Svevo come conclusione de “La Coscienza di Zeno”. Lui aveva ambientato l'ultimo giorno del suo romanzo nel 1916, agli inizi della prima guerra mondiale: era ovvio che il suo protagonista presagisse qualcosa di catastofico. La prima guerra mondiale mi ha sempre sbalordito per l'inadeguatezza dei mezzi in confornto ai metodi di combattimento: si hanno episodi di attacchi con la baionetta o cariche di cavalleria, come nelle guerre ottocentesche, che venivano massacrati da poche mitragliatrici. Anche oggi stiamo vivendo qualcosa di analogo. Forse l' “enorme esplosione” non sarà causata da un baco nel software. Gli apprendisti stregoni della finanza e della politica e di altre discipline stanno impegnandosi per arrivare prima loro.

Riferimenti Bibliografici

Segue l'elenco di alcuni libri citati nel testo

F. Dostoevskij "L'Idiota" (vi sono diverse traduzioni italiane) John Allen Paulos "A Study of the Logic of Humor” - University of Chicago Primo Levi "Il sistema periodico" - Einaudi Primo Levi "La chiave a stella" - Einaudi José Miguel Garcia "La vita di Gesù nel testo aramaico dei Vangeli" - BUR Biblioteca Univ. Rizzoli Jurgen Appelo "Management 3.0" - Addison-Wesley Stephen Covey "The 7 Habits of Highly Effective People" - Free Press Peter Drucker "Il grande cambiamento" - Sperling & Kupfer Editori Niels Pfläging "Organize for complexity" A Guide to the Project Management Body of Knowledge (PMBOK® Guide)— Fifth Edition Italo Svevo “La Coscienza di Zeno" - Einaudi

[1]

[2]

Indice dei contenuti

Glossario De pulchritudo bugorum softueris Relativismo culturale nel software Il boomerang magico Arma a doppio taglio Lo scaravoltone Ti dico che in questo momento sto tacendo! Dubbi sulla rotondità della terra. Manager scansati e lasciami lavorare Riferimenti Bibliografici Note Ringraziamenti

Ringraziamenti

Ammetto di nutrire pregiudizi negativi nei confronti di tutti coloro che si occupano di tematiche teconlogiche.

Questo ha radici antiche, forse un trauma infantile. Risale a quandi sentii una canzone di Pino Donaggio, “Archimede Pitagorico” che invitava il personaggio di Disney a darsi da fare nel suo lavoro “mentre noi stiamo qua/tutto il giorno a ballar”. Capii che non mi sarei mai dovuto occupare di tecnologia. Invece i casi della vita mi portarono a laurearmi in informatica.

Non riuscivo a capacitarmi del perchè gli altri, liberi dalle mie costrizioni, non avessero potuto studiare giurisprudenza, psicologia o altre materie più interessanti. Non scendo nei dettagli di ciò che pensavo di loro.

Ora voglio ringraziare tutti coloro che, conoscendoli personalmente, mi hanno donato il piacere di superare i pregiudizi su chi si occupa di tematiche tecnologiche. Superare un pregiudizio è veramente una sensazione bellissima.

Ai già citati Mario, Guido, Maurizio e Franco, aggiungo Laura, Valter e Andrea, ma la lista sarebbe lunghissima, incompleta e non avendo terminato le attività professionali, spero destinata ad allungarsi.

Ringrazio il prof. Piero Morandini per avermi inviato la fotografia di una larva di piralide, responsabile di pericolose contaminazioni del mais. Foto utilizzata per la copertina.