Il blog di Giordano Sassaroli

Nell’ultimo periodo ho imbiancato casa. Non essendo un professionista imbianchino, e soprattutto essendo la prima volta che lo facevo, ho distribuito nel tempo (nei vari ponti primaverili) le varie stanze della casa.

Essendo la prima volta, ho iniziato con una visita al più vicino castorama per capire i prodotti, gli attrezzi, le possibilità. E mi sono trovato spiazzato dalla varietà di prodotti. Tutti sembrano l’ottimo per la mia stanza. Peggio ancora, per quelle stanze in cui la moglie ha chiesto il colore, decine di materiali diversi con promesse di mirabolanti effetti con una passata di rullo/spugna/straccio/spatola.

Come profetizzo con i giovani in cui incappo su lavoro, in questi casi si cerca un esperto. Mi rivolgo a mio padre e a mio suocero, esperti per pratica piuttosto che per professione. La risposta che ottengo è “dipende”. Per prima cosa bisogna capire che tipo di muro è, poi che tipo di pittura è stata data l’ultima volta, poi che tipo di risultato voglio ottenere. Poi bagno e cucina sono diversi dalle altre stanze, ma anche tra le altre stanze ci possono essere differenze. Ho ottenuto un aumento mostruoso della complessità, senza risolvere il mio problema.

Io ho un muro normale (come si capisce che muro è?), non so cosa è stato dato l’ultima volta perchè non l’ho fatto io e non ero ancora entrato in casa, voglio un risultato normale (un muro pitturato, bianco da qualche parte, colorato da altre), mi sembra ragionevole di non volere che crescano muffe o piante nel bagno (c’è qualcuno che invece le cerca, che non sia un botanico malato?). C’è bisogno proprio di chiamare la scientifica per comprare una tolla di vernice?

Ho risolto comprando un libriccino da due soldi, qualcosa tipo “il manuale dell’imbianchino”, in cui in una decina di pagine mi viene data la lista della spesa per gli attrezzi e i passi (pochi e ben definiti) da fare per imbiancare una stanza, dalla preparazione all’asciugatura. Poi nei capitoli successivi, si addentra invece nei casi particolari: hai un muro ammuffito? hai delle crepe? vuoi la cappella sistina?

Ecco, provo a declinarlo nel mondo della consulenza. Troppo spesso da consulenti diamo la risposta “dipende” quando un cliente ci chiede una indicazione su una soluzione, una tecnologia, un prodotto. “dipende” è sicuramente la risposta più corretta, perchè è vero che dipende, ma non serve assolutamente a nulla al cliente. La risposta più utile sarebbe un qualcosa tipo “nel 70% dei casi funziona bene così”. Questo porta ovviamente il rischio che il cliente ci ringrazi e non ci dia altri soldi. In fin dei conti aumentare la complessità di un problema dà lavoro, perchè bisogna fare la valutazione del contesto di partenza, bisogna capire i reali bisogni, bisogna definire un modello obiettivo e poi definire la strada per raggiungerlo. Tanto lavoro. Soldi non spesi male sicuramente, perchè è l’approccio migliore per capire di cosa si ha bisogno. Ma in quel preciso momento in cui il cliente chiede una opinione, il “dipende” lascia tutto in sospeso e non serve a nessuno.

E’ corretto (anche per le tasche del consulente che si avverta poi il cliente di cosa significherebbe prendere per buona alla cieca la risposta standard. E’ vero che funziona nel 70% dei casi, ma se questo caso non fosse standard, che danni farebbe adottare la soluzione standard? Si potrebbe scoprire che non ci si smena poi tanto, ma si potrebbe anche scoprire che il rischio non vale correrlo e allora procedere con una analisi attenta.

Da qui emerge una indicazione per un approccio che consentirebbe di risparmiare soprattutto tempo. Il primo passo per provare a risolvere un problema è prendere una soluzione standard e capire se funziona e che rischio corro ad adottarla. Se mi va bene, in pochissimo tempo ho dato una soluzione al cliente, altrimenti procedo in modo classico con una valutazione approfondita del contesto e delle alternative tecnologiche.

Un’ultima nota, spesso da consulente ho usato la risposta “dipende” per prendere tempo su temi che non padroneggiavo. Vorrei ripromettermi di evitarla in futuro. Ci provo.

Una precisazione. La mia non vuole essere una campagna contro i file di testo, nè verso il loro utilizzo come mezzo per la memorizzazione del codice sorgente. La mia critica è che anche linguaggi e strumenti di programmazione di alto livello portano ancora oggi il fardello del legame con la rappresentazione fisica del sorgente. Vorrei un maggiore disaccoppiamento tra ciò che lo sviluppatore manipola e la sua rappresentazione fisica. Tale disaccoppiamento darebbe forti vantaggi a entrambi gli aspetti.

Nella stragrande maggioranza dei contesti di sviluppo software programmare significa scrivere testo. Non è sorprendente, visto che il codice sorgente è un mezzo per comunicare. L’evoluzione della programmazione è passata dal linguaggio macchina puramente binario a un linguaggio, ancora macchina, basato su mnemonici che ricordavano quanto meno l’operazione svolta. Il salto verso linguaggi di successive generazioni non ha fatto altro che alzare l’astrazione, avvicinando le espressioni e i termini utilizzati dai programmatori verso concetti più vicini al modo di esprimersi umani (ho detto esprimersi volutamente, anzichè pensare). l’evoluzione è rimasta finora legata alla parola e credo ci siano forti motivazioni per questo.

negli anni il testo del codice sorgente del sw è stato inserito all’interno di file di testo, con indubbi vantaggi. i file di testo si editano facilmente con programmi elementari che si trovano ovunque. i file di testo possono essere manipolati facilmente dai compilatori e dagli analizzatori sintattici.

l’osservazione che voglio fare è che la rappresentazione fisica del testo del codice sorgente è da sempre il file di testo, ma oggi non c’è più una motivazione a questo e il tempo è maturo per eliminare vincoli e side effect di questo legame. gli strumenti utilizzati dagli sviluppatori sono sempre più grafici e la potenza di calcolo consente di gestire una vera astrazione tra cio’ con cui lo sviluppatore ha a che fare (il testo o quel che sia il sorgente) e la sua rappresentazione fisica.

Quel che voglio discutere è che l’utilizzo di un file di testo per rappresentare il codice sorgente è stato in passato una scelta obbligata dai mezzi utilizzati dagli sviluppatori per creare il codice. Oggi questo vincolo è giustificato solo dalla storia.

Scrivere codice in un file di testo ha portato a un sacco di conseguenze che molti sviluppatori danno, senza motivo, per scontate:

• il codice viene letto dallo sviluppatore sequenzialmente. non interamente, ma comunque si viene portati a leggerlo dall’alto verso il basso. Strutture non sequenziali (condizioni, cicli) vengono per forza appiattite. metodi e funzioni vengono messi involontariamente in ordine.
• L’eredità dei parser di file di testo è che la posizione nel file di testo (non nella struttura come sarebbe più corretto) di un comando spesso determina un comportamento diverso.
• Gli sviluppatori si sono creati nel tempo convenzioni di tabulazione per facilitare la lettura e best practice di leggibilità (80 caratteri!!!!!) determinate dai display di 20 anni fa.
• Le grammatiche stesse dei linguaggi di programmazione impongono l’utilizzo dei file di testo per demarcare porzioni di codice e della struttura del software.
• alcuni linguaggi di programmazione hanno fatto di regole di tabulazione delle regole grammaticali vere e proprie.
• i limiti degli strumenti di sviluppo sono spesso legati alla struttura dei file di testo del codice

se oggi dovessimo inventare uno strumento per sviluppare software (attenzione, non ho detto per scrivere codice!) cosa proporremmo? il testo è indubbiamente un canale di comunicazione estremamente immediato per l’essere umano, ma dobbiamo per forza legarci a un file di testo? non è possibile pensare al codice sorgente come un mare indistinto di porzioni piccole di testo che si integrano a formare la base di codice di un sw? non cadremmo sicuramente nell’errore di considerare il confine del file di testo come un confine del sw, come spesso accade. certo perderemmo la possibilità di utilizzare uno stupido editor di testi per lavorare sul codice, ma non è forse meglio è più efficace avere un ambiente di sviluppo che dia tutti gli strumenti necessari a navigare nel codice, facendoci dimenticare della rappresentazione fisica del sorgente?

lancio quindi la proposta: proviamo a elencare gli scenari e le possibilità che si potrebbero avere abbandonando il vincolo legato alla memorizzazione su file di testo?

Inauguro questa nuova categoria con una giustificazione. Chiedo venia se sfioro un nuovo meta.

Ho iniziato la mia carriera nello sviluppo del sw nel 1995. Non proprio la carriera, poichè ci sono entrato da studente all’istituto tecnico. ok, i primi 5 anni sono passati con poca significatività. Sufficienti a formarmi su Turbo Pascal e Assembler. Good. I fondamenti di ciò che so ora li ho appresi in quel momento. Gran finale con una tesina di maturità (vecchia maniera) sull’Object Orientation. Col senno di poi, non ci avevo capito granchè. Bertrand Meyer non era facile come autodidatta. L’ho apprezzato solo in seguito.

I primi due anni di università ho rischiato di retrocedere. Si esce dalle superiori pensando di saper tutto, si trova un’università che non riesce a smentirti. Tristezza. Una inutile esperienza in Modula2 e una inesistente preparazione su C++.

Terzo anno, un corso su Java, il primo progettino serio. Oh. Negli anni seguenti infilo tutti gli esami possibili con un progettino di sviluppo. Gioco con il Lisp. Conosco il mondo del web sviluppato in Java con le servlet e le jhtml (quando ancora le jsp si chiamavano così).

Inizio a lavorare alla ME&S, una microsocietà di sw specializzata in strumenti di eLearning che lavora con Toolbook, una piattaforma di RAD per elearning con un linguaggio di scripting estremamente vivace. Evviva, imparo cosa significa lavorare nell’informatica e cos’è la consulenza. è il 1998. Qui proseguirò a sviluppare in Java. Qui nel 1999/2000 ci convertiamo tutti al Javascript. Venivamo dal mondo di Toolbook, interattivo, multimediale (era un concorrente di Director, l’antesignano di Flash). Non potevamo che cercare di fare altrettanto con Javascript. Ed ecco che in quei lontani anni sviluppiamo applicazioni Javascript che farebbero impallidire una applicazione AJax moderna. Qui nasce tutto il mio sapere Javascript e tutto cio’ che oggi mi consente di parlare a braccio di come funziona un browser.

Dopo aver mollato una tesi mezza iniziata di intelligenza artificiale, mi infilo in una tesi sul sw testing, per la quale anzichè far testing devo sviluppare una gran applicazione in C++. Un tool per la generazione automatica di casi di test che integra un pre-compilatore, un esecutore simbolico, un valutatore di espressioni algebriche, un analizzatore di grafi e forse altro che ho rimosso.

Sviluppo la tesi in contemporanea con il master IT del CEFRIEL e mi guadagno due titoli con una fava. a fine master, inizio a lavorare al CEFRIEL nell’area di Ingegneria del Software. Coltivo una specializzazione sulla piattaforma Java Enterprise, su cui tengo un po’ di corsi sia in CEFRIEL sia in Politecnico. Approfitto di un progetto per giocare anche con la piattaforma Eclipse e prendermi un po’ di competenze anche nello sviluppo su architetture a plugin.

Col tempo, perdo dimestichezza col C++. Nel 2005 però derivo dal mondo Java per circa 4 mesi, sviluppando in C# una architettura per l’integrazione di strumenti di domotica sul Windows Media Center. Si parla di Universal Plug & Play.

Lascio il C# e mi infilo nel Python per un po’ di 2006. si sviluppa (giocando anche con Scrum) una piattaforma per la predizione di flussi di traffico sulla rete di milano. Non male.

Ultimamente ho perso un po’ il ritmo, poichè son passato dalla parte oscura della forza (sono PM). Non mi va di aspettare oltre a dir la mia. Oltre suonerebbe solo come un rimpianto. Spero valga il penny.

Il titolo e’ una citazione di Samuel Beckett (http://en.wikipedia.org/wiki/Samuel_Beckett), l’ho trovata tempo fa e da allora la considero una delle migliori citazioni che conosca. Se devo essere sincero, in genere non mi ricordo le citazioni. Questa sì e quindi la considero di rilievo.

Voglio parlare di esperti e di fallimenti. Sostituite la parola esperti con senior o professore e il discorso non cambia. Ciò che rende un esperto ammirevole ai nostri occhi è che ha la capacità di evitare le insidie che porterebbero a un fallimento, proprio quelle in cui noi caschiamo o cascheremmo. Poichè le capacità innate non hanno nulla a che fare con l’essere esperti, ciò che li contraddistingue da noi è che hanno già fallito laddove noi non siamo ancora arrivati e che sono stati in grado di imparare dal fallimento. Hanno già passato nottate a risolvere un problema in un software o sono già stati cacciati via da un cliente insoddisfatto.

Le cose che secondo me sono importanti da ricordare:

• Si fallisce a qualunque età e grado di esperienza.
• Bisogna cercare di essere sempre in qualche modo in contatto con qualcuno di più “esperto” che possa aiutarci a evitare un fallimento o almeno a interpretarlo per evitare di ricascarci.
• Non bisogna vergognarsi dei propri fallimenti. e’ il modo di diventare esperti.
• Ancora più importante del precedente, non bisogna vergognarsi di chiedere aiuto. Non è un segno di debolezza bensì una dimostrazione della ammirevole volontà di evitare un fallimento.
• Non ci sono temi più soggetti al fallimento di altri. Si può chiedere aiuto per un pezzo di codice, per un algoritmo, per delle slide o per la gestione di un progetto.

Dopo aver installato una nuova canna fumaria e cambiato la caldaia (tutto a causa di minacciosi adeguamenti alle norme di sicurezza), mi trovo gentilmente obbligato a dover cambiare il tubo del gas che, essendo “pinzato” anzichè “saldato” mi rende tutto l’impianto incertificabile.

L’idraulico (tecnico) alla prima occhiata aveva detto “è un gran casino, per cambiare il tubo bisogna smontare tutta la cucina”. E già (dopo aver convinto la moglie che la conservazione della cucina in frassino era la mia massima priorità) avevamo preso contatto con i falegnami per capire l’entità dello sforzo. Ecco che a un secondo sopralluogo il capo dell’idraulico (consulente) afferma che “si può tranquillamente far passare il tubo sotto i mobili”, affermazione che sfida anche le conoscenze di geometria di un infante. Ma ci vogliamo credere e diamo il via. Eccoci a ieri, con l’idraulico (il tecnico) che entra in cucina con un bel “qui se non smontiamo tutto non combiniamo niente”.

Io (responsabile dell’infrastruttura) devo difendere lo status quo della qualità della mia cucina, per la quale ho speso i miei bei soldini qualche anno fa. Per contro, l’intervento evolutivo sul tubo non può essere rimandato. Dico “non si possono sfilare solo due armadietti lasciando stare la colonna e il lavello? almeno così non spostiamo nemmeno il piano di lavoro”. Questi tentennano, poi si decidono a cominciare.

Per tutta la mattina non fanno altro che dire “non si riesce mica a lavorare con sti mobili” o “meno male che stiamo riuscendo ugualmente, ma sembrava impossibile”. Durante il lavoro gli fornisco anche un asse di legno e della carta vetrata. Sul primo poggiano i tubi mentre li saldano (e se non l’avessi avuto dove avrebbero saldato? per terra?), con la seconda lisciano i tubi tagliati (ma gli strumenti di lavoro non se li dovrebbero portare loro?).

A un certo punto affermano “abbiamo finito, ora 1o minuti e controlliamo la tenuta così andiamo a mangiare”. Ovviamente la tenuta non tiene, “vediamo se c’è puzza di gas, rimisuriamo, magari è colpa dello strumento difettoso”. ci mettono un’ora per arrivare a chiudere il lavoro.

Conclusione io mi trovo il lavoro fatto ma ho anche

1. l’impressione che se non avessi proposto io di togliere due armadietti, loro non avrebbero neanche iniziato portandomi a chiamare il mobiliere con un impatto enorme.
2. l’idea che se non avessi fornito il legno, avrebbero saldato a terra o chissà dove.
3. meno fiducia nel loro lavoro, dopo l’affermazione “10 min e andiamo” smentita in un minuto.
4. meno fiducia nei loro strumenti dopo che hanno indicato una perdita, poi una leggera perdita e poi nessuna perdita.

Perchè scrivere di questo episodio? perchè mi son fermato a pensare a cosa pensano i clienti quando andiamo a installargli un prodotto (deploy in gergo):

• per i tecnici è sempre un lavoraccio, per i consulenti una passeggiata
• spesso è il cliente a suggerire una soluzione per togliere d’impiccio. A lui resta l’impressione di saperne di più, o comunque di avere le idee giuste.
• i tecnici si lamentano di qualunque vincolo e lo rendono insormontabile. per il cliente i vincoli hanno un significato (la cucina sana, i firewall attivi) a cui difficilmente sono disposti a rinunciare o su cui rischiare.
• i tecnici a volte improvvisano gli strumenti di lavoro (”aspetta che mi scarico l’ultima versione di sqlDeveloper”) e così perdono credibilità
• immancabilmente a 5 minuti dalla fine qualcosa smette di funzionare e ci si perde la credibilità rimasta.

Ora, io ho vissuto più volte il ruolo del tecnico e so cosa significa. Questa volta ho vissuto la parte del cliente. Mi sono fermato a pensare e ho dato in un attimo tutta la mia solidarietà ai clienti che han subito negli anni i miei interventi. Un po’ più di sensibilità a piccoli particolari fa sì che, indipendentemente dal successo del risultato, la nostra credibilità agli occhi dei clienti sia sempre elevata.

Ah, del nuovo tubo sono soddisfatto comunque, son convinto che abbiano fatto un ottimo lavoro.

Perchè aprire un blog la notte di Pasqua? Ecco qualche risposta:

1. Perchè è Pasqua. Di solito se a quest’ora sono al PC è perchè devo lavorare. Ieri ho imbiancato e oggi sono stato in giro. Ho la mente abbastanza sgombra per pensare ai fatti miei.
2. Perchè mia moglie è incinta e va a dormire presto, quindi ho una maggiore propensione a fare altro che dormire.
3. Perchè ieri, oltre che imbiancare, ho ricevuto degli operai in casa che mi hanno stimolato un ragionamento, che diventerà il mio primo blog che non parli del mio blog (odio i blog autoreferenziali, meta-blog, o simili e sono già al secondo entry per cui devo piantarla).
4. Perchè oggi il dottor House è finito presto e mi dato il tempo di pensare a quale sarebbe potuto essere il mio blog hosting service (vecchia puntata del dr, ma ormai è come John Wayne e così “questo non l’ho mai visto”).

Dopo che milioni di persone si son fatti trascinare nel vortice del web e del blogging, ecco che, alla fine, anche io mi decido.

Ho sempre affermato che scrivere un blog è un po’ come appendere un post it sulla facciata del duomo di Milano. A chi vuoi comunicare? Che tipo di risposta ti attendi? Pensi di tornare dopo un paio di giorni e vedere nuovi post it sotto il tuo, che danno risposte?

La risposta è “forse sì”: i frequentatori di piazza del duomo forse non sono ancora pronti per accettare in modo civile e collaborativo lo strumento del post it, ma i frequentatori del web credo che ormai lo abbiano dimostrato.

Devo ammettere di aver atteso parecchio prima di lanciarmi. Visto il mio mestiere (sono Ingegnere del Software al CEFRIEL, un centro di innovazione dell’ICT e mi occupo di tecnologie web) avrei potuto svegliarmi prima. La diffidenza verso il mezzo mi ha trattenuto. E un po’ anche un pizzico di bastiancontrariaggine che mi spinge a non seguir la moda quando ormai era evidente la nascita e la maturità di un mezzo di comunicazione.

Dopo un paio d’anni di intranet aziendale, mi sento in vena di partire. Per cui: “buongiorno blog”.