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.

Il software è profondamente diverso. Il software è interamente prodotto da un’attività cognitiva. Due persone diverse, pur con le stesse competenze tecniche, hanno capacità di problem solving e di astrazione diverse. Pensano in modo diverso. Costruiscono modelli mentali diversi. E scriveranno il software in base a questi modelli mentali. Due sviluppatori non sono mai totalmente intercambiabili. Il fattore umano nello sviluppo di software è cruciale, molto più che in altri settori.

Il problema va declinato anche in termini di figure professionali. Attorno allo sviluppatore dovrebbero ruotare professioni diverse, come l’analista o l’architetto del software. O il project manager con una formazione orientata al software. Se non viene compresa la natura profonda di cosa sia il software, tutto è perduto. L’analista non può essere un “programmatore invecchiato” :-), né è sufficiente diventare esperti di dominio per essere degli analisti.

Il problema in definitiva è culturale. Da un lato le aziende e dall’altro la formazione, nelle università, negli istituti professionali, nei corsi professionalizzanti. Se le aziende continueranno a vedere il software come una commodity, come merce, come puro costo da ridurre, la gran parte degli sforzi per governare la complessità dei sistemi sarà destinata a fallire. Il software non è una commodity. Il software è un asset di conoscenza. I processi di sviluppo dovrebbero essere ancorati su questa convinzione, incentivando gli sviluppatori a lavorare su un modello mentale esplicito. Documentato. Negoziato e condiviso. Tradotto in codice. Tradotto in architettura. Tradotto in test automatici. Ragionando a ritroso, è facile vedere in questa mia posizione chiari richiami alla tecnica del Domain-Driven Design. Ma questa è solo metà della storia. Dall’altro lato serve acquisire competenze mirate, derivanti non solo dall’esperienza e dalla conoscenza di dominio. Serve acquisire competenze nell’analisi. Formare figure interne preposte al controllo della qualità, con il mindset del testing (solo per fare un esempio). Serve riconoscere questi ruoli, dargli una dignità esplicita. Non è solo un problema di risorse: è principalmente una questione di maturità. Come industria.

Possiamo costruire software di qualità. Che fa quello che deve fare e lo fa bene. Che è facile da usare, documentato e facile da modificare. E che è anche sostenibile economicamente.

Costruire software di qualità tecnicamente si può.

Ma dobbiamo alzare la priorità.

La qualità non è un problema di spaghetti o lasagne, di pattern o di tecnologia, né di linguaggio di programmazione o di metodologia: è una questione di visione e cultura.