“Crediamo che faccia parte del dovere professionale dell’ingegnere del software il puntare a un’alta qualità dei prodotti, e in particolare alla loro affidabilità. Questo dovere professionale deve, se è il caso, far prendere una posizione intransigente nei confronti di chi vorrebbe far sviluppare un’applicazione entro vincoli di tempo e di investimento inadeguati”.
La frase precedente, che mi ha accompagnato per tutta la mia carriera, è una citazione tratta da un vecchio di libro sull’Ingegneria del Software che mi sono ritrovato a comprare, giovane e idealista studente di Ingegneria Informatica, nei primissimi anni novanta.
L’acquisto del libro era stato dettato dall’effetto che aveva suscitato in me un racconto contenuto nell’articolo de “Le Scienze” che ne annunciava l’uscita.
L’articolo infatti raccontava la storia del Vasa, il galeone orgoglio della flotta Svedese costruito assecondando le idee di grandezza del sovrano dell’epoca, che resero la nave troppo lunga, con troppi ponti per i cannoni e con gli alberi delle vele troppo alti.
Il Vasa affondò nel porto di Stoccolma il giorno stesso del varo, il 10 agosto 1628, rovesciandosi su un fianco per una folata di vento (cosa triste assai per un veliero).
Quel giorno, diceva l’articolo, nacque l’ingegneria navale, poiché ci si rese conto che le navi avevano raggiunto delle dimensioni e una complessità tale, per cui non potevano più essere un affare solo “artigianale”, da capo mastro, ma necessitavano di un insieme di regole matematiche e fisiche che, come già accadeva per le costruzioni terrestri, dovevano fare da guida per la costruzione delle navi stesse. Allo stesso modo, concludeva l’articolo, il Software divenuto oramai uno strumento sempre più pervasivo nella vita dell’uomo, necessitava della creazione di una sua “Ingegneria” per evitare di incorrere in disastri come quello del Vasa.
All’interno del libro veniva dettagliatamente esposto il classico ciclo di sviluppo del software waterfall, accennando poi a metodi alternativi, come modelli evolutivi e di prototipazione e veniva fatta una disamina sull’importanza di argomenti quali Affidabilità, Correttezza, Robustezza, Sicurezza, Prestazioni, Usabilità, Manutenibilità e via enunciando.
Quel libro era anche “tempestato” di formule matematiche e metodi di conteggio della complessità, che aggiungevano “rigore ingegneristico” alle metodologie enunciate, insieme ad un’infarinatura sulla gestione di un progetto che avrebbe fatto felice il mio docente di PMP.
Questo lungo preambolo rende evidente come certe tematiche “attuali”, non siano nate con il web o con le App, ne tanto meno con il Cloud, ma sono temi che chi lavorava con il software affrontava già quando la questione più dibattuta era se erano meglio gli Spandau o i Duran (meglio i primi ovviamente).
E quindi? Con un approccio così rigoroso già dai primordi cos’è che andato storto? Cosa ha reso il Dev tanto lontano dall’Ops per cui è stato necessario (re)inventarsi una metodologia per riavvicinarli?
Questa è la domanda con cui ci siamo lasciati nel post precedente, e che approfondiremo anche dei post successivi, ma temo che il germe della sconfitta, il nome del “colpevole”, come mi ha chiesto l’amico Marco nel suo commento al post già citato, fosse presente nello stesso libro, nascosto in una citazione delle Lezioni Americane di Italo Calvino, che recita:
“E’ vero che il software non potrebbe esercitare i poteri della sua leggerezza se non mediante la pesantezza del hardware; ma è il software che comanda, che agisce sul mondo esterno e sulle macchine, le quali esistono solo in funzione del software, si evolvono in modo d’elaborare programmi sempre più complessi.”
E’ il software che comanda….
Per qualche strana ragione nel corso del tempo il rigore ingegneristico nella realizzazione delle applicazioni si è perso (diciamo diluito va), a botte di budget ridotti, time to market (non c’è mai tempo di fare le cose bene, ma c’è sempre tempo per rifarle), abbattimento (almeno in Italia) della retribuzione e, di conseguenza, della qualità media dei programmatori rendendo, di fatto, abbastanza “randomica” il funzionamento dei software che vengono messi in produzione (siamo nell’era della continuous beta) e, di conseguenza, quasi impossibile la vita a quelli che quelle applicazioni devono farle girare, gli Ops appunto.
Però una cosa è rimasta invariata nella testa dei programmatori, la frase “è il Software che comanda”, che spesso viene tradotta in:” il Software è una creazione artistica, un’espressione dell’intelletto umano, non potete pretendere anche che funzioni!”.
E quindi, signori, guardiamoci negli occhi, ogni volta che noi Dev abbiamo fatto qualcosa stile “mettici una pezza, poi la sistemiamo” per lasciarla puntualmente com’era, oppure “anche se è lenta non preoccuparti, aggiungiamo altri nodi al cluster” e via cialtronando, ogni volta, abbiamo allontanato da noi di qualche metro gli Ops, irrigidendone le posizioni nei nostri confronti e facendo si che ci vedessero come un nemico da abbattere.
Il colpevole siamo noi.
Per questo insisto sempre sul fatto che il DevOps non può ridursi solo all’uso di tool più o meno intelligenti, per fare più velocemente le cose o anticipare i problemi più a monte nella catena di sviluppo, lo “shift left” tanto caro ai modaioli.
In queste condizioni di conflitto costante, l’unico modo per far funzionare realmente il DevOps è che alla base ci sia una nuova Cultura Applicativa, che riprenda parte del rigore del passato per migliorare la qualità complessiva di quello che facciamo, mantenendo però la piena consapevolezza di ciò che accadrà all’applicazione quando “uscita dal porto” del Dev, dovrà “navigare” nel mare dell’Ops, passando quindi dalla creazione intellettuale di qualcuno allo strumento di lavoro di qualcun altro.
La cosa non è semplice, un salto culturale non lo è mai, ma ritengo sia l’unico modo per riavvicinare i due estremi e rendergli evidente che la nave su cui si sta navigando è la stessa, e, se non si vuole fare la fine del Vasa, è il caso di lavorare insieme per mantenerla in rotta.
Presa coscienza di questo i temi quali la condivisione, le nuove modalità operative, i nuovi cicli di sviluppo e, infine, i tools, di cui parleremo nei prossimi post, sono degli utili strumenti, ma non sono il cuore del DevOps, il cuore del DevOps è la voglia, il piacere di lavorare insieme per portare un’Applicazione alla prova degli utenti e la coscienza di come farlo nel migliore dei modi.
Io ho avuto la fortuna di provarlo quando ho fatto giocare mezza Italia a poker online, non si chiamava ancora DevOps ma il succo era quello e, fidatevi, è una gran bella sensazione.
Alla prossima.