SPAGHETTI, LASAGNE, RAVIOLI E SOFTWARE

Recentemente sulla rete sta girando un post che, attraverso una simpatica vignetta, ripercorre trent’anni di evoluzione industriale delle architetture software. La metafora utilizzata per descrivere i tre modelli di riferimento citati è quella culinaria. Si parte dalle architetture “Spaghetti-oriented” degli anni ’90, per arrivare alle architetture stratificate, applicazione monolitica del pattern Layer (Lasagna-oriented), e per finire poi nella decade corrente con l’approccio a microservizi (Ravioli-oriented). La vignetta termina con una domanda: What’s next? (Che cosa verrà dopo?)

Qualunque sia la risposta, il vero problema a mio avviso non è tecnologico: è capire quanto velocemente come industria riusciamo a colmare il gap tra i modelli di riferimento teorici e la pratica di ogni giorno. La gran parte dei sistemi software, nonostante la diffusione (orale e scritta) di molti stili architetturali e pattern specifici, è oggi ancora monolitica, spaghetti-oriented, priva di documentazione, insufficientemente collaudata e senza un’architettura di riferimento (spesso senza neanche un progetto esplicito). Ciò che è peggio è che questa situazione finisce per accomunare sia i progetti legacy, sia quelli nuovi, che potrebbero nascere in condizioni di maggior controllo e autonomia di intervento. Questa considerazione suggerisce che il problema essenziale non è tecnico, ma culturale. Si tratta di un problema che origina dal modo in cui consideriamo il software e le figure professionali che ci ruotano attorno.

In molte realtà il software è visto come una commodity, una sorta di materia prima che si acquista in blocco, oppure si produce e si incorpora in un prodotto come se si stesse assemblando un tavolino. Merce. Con le “giuste istruzioni”, basta prendere un operaio qualsiasi (con tutto il rispetto per questa figura) che lavora in una catena di montaggio e si otterrà il medesimo risultato. Se bisogna costruire un impianto termico si interpella un idraulico. La valutazione di quale idraulico chiamare cadrà su fattori come il costo e la vicinanza, non sulle sue competenze. Perché? Perché si parte dall’assunzione che tutti gli idraulici hanno competenze simili. Sono, in un certo qual modo, intercambiabili.