La domanda è mal posta…

Nel precedente articolo abbiamo visto un caso — quello degli incidenti occorsi agli aerei Boeing 737 MAX 8 e legati a quanto pare a difetti del software — che fa riflettere su quanto possa costare sul lungo periodo un risparmio sul breve termine. Va tenuta in primo piano anzitutto la perdita più grave e non convertibile in termini economici, quella delle vite umane; ma quel caso ci insegna che un taglio ai costi, quindi un iniziale risparmio, si è poi trasformato in una concatenazione di conseguenze che ha portato a gravi perdite per l’azienda.

Ma attenzione: questo è un caso limite. Siamo in un ambito, quello aeronautico, intrinsecamente soggetto a considerazioni legate alla sicurezza e alla incolumità delle persone che usufruiscono del servizio.

Quello che ci vogliamo chiedere in questo secondo articolo è invece un interrogativo del tipo: “Ma in una situazione non mission critical, i costi connessi allo sviluppo di un prodotto di qualità sono giustificati dai ricavi che tale prodotto di qualità è in grado di garantire?”.

Se per un servizio che riguarda la vita o la salute delle persone, o anche l’integrità delle transazioni economiche, è evidente — o dovrebbe esserlo — che tagliare i costi in maniera poco oculata può portare alla rovina, ribaltare il discorso non è così scontato.

Ossia… Immaginiamo un’organizzazione che realizzi un gioco, o un’app di messaggistica, o un servizio per la ricerca e la prenotazione di stanze in strutture ricettive. Perché una azienda, un Product Owner, un gruppo di sviluppatori dovrebbero concentrarsi anzitutto sulla qualità del prodotto, con conseguente aumento dei costi di produzione, se possono fornire un servizio non mission critical comunque abbastanza buono e tutto sommato soddisfacente per l’utente finale, sviluppandolo con un certo risparmio?

Come avrebbe detto un Corrado Guzzanti d’annata impersonando il guru new age profeta di Quèlo [1], “La domanda è mal posta”. E la ragione, l’avete già capito, è che occorre anzitutto mettersi d’accordo su cosa significhi “qualità”.

Il successo di McDonald’s

Tutti conosciamo la catena di ristorazione fast food McDonald’s: indipendentemente dal giudizio sui valori gastronomici e nutrizionali del cibo servito, è interessante conoscere alcuni aspetti chiave del successo globale di tale catena.

Un film del 2016, intitolato The Founder ha raccontato, in modo abbastanza vicino alla realtà, la nascita della grande catena nazionale — e poi globale — di fast food McDonald’s, cominciata dalla metà degli anni Cinquanta ad opera di Ray Kroc, un imprenditore con un grande fiuto per gli affari, un’invidiabile perseveranza e anche una notevole dose di spregiudicatezza… Ma l’idea della ristorazione “veloce”, in cui i cibi venivano serviti in tempi molto più brevi rispetto a quelli di una “normale” struttura di ristorazione, era nata alcuni anni prima in California, nel ristorante dei fratelli McDonald con i quali Kroc entrò in società, finendo poi per estrometterli dal business rilevando tutte le quote della corporation.

I fratelli McDonald, in particolare Dick, avevano messo a punto un sistema ottimizzato per la produzione veloce degli hamburger e degli altri cibi serviti ai clienti, battezzandolo “Speedee Service System” [2] che, pur con tutti i cambiamenti intervenuti nei decenni, è ancora alla base di quanto accade oggi in ogni fast food.

Dove sta la qualità?

Se sembra che stiamo divagando, in realtà non è così. Chiediamoci subito: in un modello come questo dove sta la qualità? Il mondo in cui nasce il fast food —quello statunitense del secondo dopoguerra, proteso verso un’incredibile e apparentemente inarrestabile crescita economica, dominato dalla velocità e dall’efficienza — ha proprio bisogno di questo: velocità e praticità nel consumare i pasti. E la “qualità” di questo modello sta proprio nel soddisfare un mercato di persone che si spostano molto di più, spesso in macchina, e non vogliono sprecare gran parte della loro pausa pranzo ad aspettare che il cibo sia preparato.

La McDonaldizzazione della società

Ma andiamo oltre: il successo di questo modello è diventato globale e, nonostante alcuni piccoli ridimensionamenti degli ultimi anni, di fatto McDonald’s impiega a tempo pieno più di 400000 persone in tutto il mondo… Ma questo modello è stato anche oggetto di ricerca — e di critiche — da parte di vari studiosi. Il termine McDonaldization, da noi poco usato, è invece piuttosto diffuso negli USA e in altri Paesi di lingua inglese.

Inizialmente proposto nel 1995 da George Ritzer, professore di Sociologia presso l’Università del Maryland, e illustrato in un libro giunto ormai alla nona edizione [3], il concetto di “McDonaldizzazione” ha trovato ampio riscontro nella discussione sugli sviluppi della società e del lavoro negli ultimi venti anni.

Ma cosa si intende con il termine McDonaldization? In pratica l’autore osserva che ormai la società ha esteso a tutto il suo ambito quei principi che erano stati inizialmente sviluppati dall’industria del fast food. Ma quali sarebbero questi principi? Secondo Ritzer si tratta di

• efficienza: semplificazione e ottimizzazione dei processi per raggiungere obiettivi;
• calcolabilità: la prima misura del successo è la quantità di prodotto erogato, non la qualità o la particolarità dello stesso;
• standardizzazione: se c’è un prodotto che funziona, sarà sempre uguale a sé stesso;
• controllo “sociale”: abbigliamento e comportamenti uniformi garantiscono che l’interazione con il personale non crei differenziazioni nell’esperienza dell’utente;
• irrazionalità derivante dalla razionalità: paradossalmente — e questo è forse uno degli aspetti più interessanti della teoria di Ritzer — un sistema razionale, efficiente ed efficace come quello dei fast foodfinisce per ottenere risultati controversi, specie sul personale che viene privato di spirito di auto-organizzazione e capacità operativa autonoma, al punto di essere quasi “de-umanizzato” nei casi estremi.

Chiaramente si tratta di una schematizzazione anche abbastanza estrema, ma molto efficace. L’osservazione di Ritzer è che molti processi del nostro modo di lavorare e produrre, e anche di organizzarci in società, hanno assorbito questi aspetti dell’organizzazione tipica di una ristorazione fast food: prodotti standard, erogati in grandi quantità, conformi alla mentalità di chi li produce e li consuma. Non sono mancati interventi che hanno applicato il concetto di McDonaldizzazione al mondo del lavoro digitale [

Torniamo al software

Dopo queste riflessioni “generali”, torniamo al software? Sappiamo dire che cosa sia un software “di qualità”? Abbiamo visto, con la metafora del fast food che probabilmente il cibo servito non è il più particolare o legato al territorio che ci sia — e in questo senso molti potrebbero dire che la qualità non è elevata — ma è quello che soddisfa molti clienti per il costo accessibile e la velocità con cui viene servito. Vediamo allora di applicare ai processi di sviluppo del software alcune delle considerazioni appena viste.

Quando affermavamo che “La domanda è mal posta” volevamo dire anzitutto che in una attività complessa come quella dello sviluppo del software — complessa per il veloce mutamento degli scenari e delle infrastrutture tecniche, per la necessità di scalare che a volte si manifesta improvvisamente, per il mercato pieno di concorrenza e anche per una certa dose di “creatività” che necessita, se non in tutte, almeno in svariate componenti del processo di produzione e rilascio — semplificare al massimo le azioni inerenti il rapporto costi/qualità rischia di risultare una falsa soluzione. Se il compromesso “Standardizzo il prodotto su un livello di qualità non eccelso, ma posso produrlo in quantità e renderlo disponibile in tempi velocissimi” può funzionare nel fast food, non è detto che esso si trasferisca senza mutamenti al mondo del software e delle industrie “creative”.

Insomma, la McDonaldizzazione avrà sicuramente interessato anche l’industria dello sviluppo del software, ma se è vero che in molti casi gli sviluppatori devono sfornare degli “hamburger” o dei “cheeseburger” sempre simili a sé stessi, è anche vero che in tanti altri casi a loro è chiesto di realizzare dei “piatti originali” che richiedono le conoscenze di uno chef stellato e la competenza di un’intera brigata di cuochi raffinati.

Qualità esterna e qualità interna

Diciamo subito che, nell’ambito del software, quando parliamo di qualità, molto dipende dalla prospettiva in cui ci poniamo.

C’è una qualità esterna, vale a dire ciò che viene percepito dall’utente finale:

• questa app, questo servizio soddisfano le mie necessità?
• sono facili da usare / hanno una interfaccia utente funzionale e “bella”?
• vengono aggiornati a intervalli ragionevolmente ravvicinati?
• hanno un costo accessibile / che mi appare congruo per i problemi che risolvono?

e così via.

Ma c’è poi anche una qualità interna del software, che è percepita innanzitutto da chi quei programmi deve contribuire a svilupparli, a manutenerli, ad aggiornarli, a farli evolvere:

• il codice sorgente è facilmente leggibile?
• l’architettura è chiara e comprensibile?
• c’è una chiara modularità che consente di capire dove andare ad agire per modificare determinati funzionamenti dell’applicazione?

e quant’altro…

A ciascuno di noi appare chiaro che la qualità esterna di un’app può essere più o meno evidente, ma di sicuro è percepibile dagli utenti finali. Al contrario, la qualità interna, per quanto assolutamente auspicabile, è sicuramente a beneficio di chi sviluppa, ma non sarà quantificabile dall’utente finale.

Qui arriva il primo “inganno” concettuale: se allora dobbiamo tagliare qualcosa, meglio tagliare sulla qualità interna purché ovviamente non ne venga influenzata la qualità esterna. Finché riusciamo a rilasciare software funzionante a intervalli sufficientemente brevi, il gioco sta in piedi e non ha senso spendere di più per garantire un livello di qualità ulteriore che, al nostro utente finale — vero obiettivo di quello che facciamo — comunque non arriva.

In realtà il discorso è esattamente al contrario: se all’utente qualcosa non arriva, non è quello l’ambito su tagliare i costi. I costi andranno casomai tagliati proprio su quello che l’utente percepisce, perché, vedendo cosa c’è di migliore o di fatto meno bene in due applicazioni simili, potrà scegliere se spendere quei soldi in più che gli appariranno giustificati o meno dalla qualità esterna che riesce a valutare.

Ma oltre a questo discorso, c’è un motivo in più per cui la qualità interna forse merita una maggiore attenzione.

Debito tecnico

Eppure, come è scritto nell’Agile Manifesto [5],

La continua attenzione all’eccellenza tecnica e alla buona progettazione esaltano l’agilità

È un dato di fatto che gran parte del lavoro di un programmatore consista nel modificare codice esistente e, anche laddove apparentemente si “parta da zero”, si finisce in realtà spesso per attingere a una code base preesistente. Che succede se il codice è difficilmente leggibile? Se la logica è intricata, se i dati sono difficili da seguire, se i nomi sono usati senza coerenza e con eccessiva “fantasia” come sicuramente sarà capitato di riscontrare a molti di voi?

Questo scarto tra la situazione reale del codice e il suo stato ideale diventa un aggravio di “spesa” in termini di impegno e tempo necessario per venire a capo dei problemi. Questo aggravio viene comunemente definito debito tecnico e, come tutti i debiti, più esso si accumula più diventa difficile estinguerlo.

Il debito tecnico accresce il tempo necessario a comprendere il codice, rende difficoltoso l’interscambio tra persone diverse che ci debbano lavorare sopra, aumenta la possibilità di errore. Per carità, gli errori e i rallentamenti ci saranno anche nel caso di assenza o minima incidenza del debito tecnico, e con i migliori team di sviluppo: ma c’è una misura nelle cose e un conto è il normale scarto fisiologico, altro è la patologia inveterata.

Aggiornamenti e nuove funzioni

Ma un codice ad alta qualità interna rende anche più facile migliorare il codice e aggiungere nuove funzionalità. E qui la qualità interna si riversa direttamente su quella esterna, con soddisfazione da parte dell’utente finale che apprezza l’arrivo di nuove funzioni (utili) e i rapidi aggiornamenti.

Un’applicazione che abbia uno stile architetturale a microservizi, ad esempio sarà intrinsecamente più adatta all’evoluzione e al miglioramento di un “monolite”, anche se entrambe le applicazioni svolgono gli stessi compiti con la stessa soddisfazione per l’utente finale.

Qui, in effetti, si può parlare di “compromesso” tra qualità e costi. La ricerca di una più elevata qualità interna avrà sicuramente un impatto significativo sui costi di sviluppo, specie nelle fase iniziali del ciclo di vita dell’applicazione. Il ruolo fondamentale della qualità interna è che abbassa il costo del cambiamento in futuro. Ma sul breve termine gli investimenti dovranno necessariamente essere maggiori. E qui si tratta di fare le valutazioni più opportune, se valga la pena che sul medio e lungo termine i costi maggiori saranno probabilmente giustificati da una maggiore adozione dell’applicazione.

Conclusioni

Tralasciare la qualità interna del software crea debito tecnico che finirà per rallentare lo sviluppo futuro. Al contrario, alta qualità interna del software, con una continua attenzione all’eccellenza tecnica e alla riduzione immediata del debito tecnico, consente una migliore evoluzione del software, con l’aggiunta di funzionalità nel lungo termine che comporta minor costi in termini di tempo e impegno.

Le pratiche per raggiungere questi risultati (approccio agile alla gestione del processo, team cross-funzionali auto-organizzati, stili architetturali a microservizi, pratiche DevOps) esistono ormai da qualche tempo. La svolta sta nel comprendere la relazione controintuitiva tra aumento dei costi e qualità interna del software e adottare comportamenti conseguenti.