Sviluppare software di bassa qualità costa di più, e ci si mette più tempo.
Può sembrare un paradosso, ma non lo è: le tecniche e le pratiche che aumentano la qualità del software fanno sì che lo sviluppo costi meno, e quindi hanno senso anche e soprattutto dal punto di vista economico, come spiega Martin Fowler in Is High Quality Software Worth the Cost?
Le scelte compiute nei progetti software possono avere conseguenze devastanti, come nel caso del sistema di controllo di volo dei Boeing 737 Max 8.
Le considerazioni di Bob Martin sul caso dei due aerei caduti in pochi mesi: http://blog.cleancoder.com/uncle-bob/2019/05/18/737-Max-8.html
Come evitare conflitti in un rapporto di outsourcing, riducendo il rischio di conseguenze legali? Un campionario di worst practices nell’articolo di Capers Jones “Minimizing the Risk of Litigation”, nel numero di settembre 2016 di CrossTalk.
I progetti hanno bisogno di manager? Sì, ma hanno bisogno soprattutto di buoni capisquadra, capaci di controllare nel merito e di assicurare la qualità di ciò che si produce.
Where is the Foreman? e Oh Foreman, Where art Thou? , di Uncle Bob Martin.
Una ricerca spesso citata sullo sviluppo software è il Chaos Report, pubblicato periodicamente a partire dal 1994 dallo Standish Group. Il Chaos Report classifica i progetti in tre categorie: successo (risultati coerenti con i requisiti iniziali, forniti nei tempi e con le risorse previsti); discutibili (risultati inferiori alle attese e/o tempi e/o costi maggiori); fallimenti.
I dati del Chaos Report si possono interpretare in diversi modi: una critica ragionevole in questo articolo di Scott Ambler sul Dr. Dobb’s Journal: The Non-Existent Software Crisis: Debunking the Chaos Report.
Per diventare “campioni” in una disciplina servono almeno 10.000 ore di esercizio, ma la pratica da sola non è sufficiente, il talento è decisivo.
In un ambito multidisciplinare come lo sviluppo software, comunque, è essenziale che gli specialisti collaborino tra loro per il successo dei progetti, anche svolgendo attività al di fuori della loro specializzazione, come argomenta Jim Coplien in “Can You Scrum Art?“.
“La tracciabilità deve essere pianificata a livello strategico. Tipicamente, tracciare ogni singolo requisito non è né sensato dal punto di vista dei costi né particolarmente utile. Anzi, questo livello di tracciabilità porta probabilmente a creare un’infrastruttura documentale non mantenibile […]. La tracciabilità, per essere efficace, deve vivere e respirare in linea con il sistema che supporta.”
In Thinking about Quoins: Strategic Traceability of Architecturally Significant Requirements (su IEEE Software, settembre-ottobre 2013) Jane Cleland-Huang propone di tracciare solo i requisiti che influenzano le scelte architetturali, ma di farlo attivamente e in modo sistematico, misurando nel tempo le evoluzioni del sistema rispetto ai suoi requisiti.
In un articolo precedente Strategic Traceability for Safety-Critical Projects (su IEEE Software, maggio-giugno 2013, a pagamento), Cleland-Huang e altri analizzano la validità delle informazioni di tracciabilità inviate dai produttori di sistemi critici alle autorità competenti per il loro controllo, e propongono tecniche per migliorarne l’efficacia.
Gli errori sono inevitabili. Nell’hardware, nel software, nell’uso che ne facciamo. Quando poi i sistemi sono attivi nel cloud, la complessità globale aumenta, ed aumentano di conseguenza i possibili errori. Come ridurli, o ridurne gli impatti negativi?
In The Antifragile Organization (su Communications of the ACM, agosto 2013 – articolo a pagamento) Ariel Tseitlin propone di non basarsi solo su verifiche in ambiente di test, ma di provare a creare in modo sistematico malfunzionamenti anche sui sistemi in esercizio, per renderli progressivamente sempre più robusti: “Embracing failure to improve resilience and maximise availability”.
Quando il software è fatto bene, gli utenti lo usano senza problemi. Chi dà assistenza non è subissato dai reclami. Per chi lo fa evolvere è facile aggiornarlo, modificando le funzioni esistenti quando è il caso, o introducendone di nuove.
Non tutti, purtroppo, viviamo in questo mondo ideale. Non sempre, almeno. Perché il software può essere anche fatto male, e (se lavoriamo nel settore dello sviluppo software) può darsi che l’abbiamo fatto male noi.
Perché, a volte, il software è fatto male? In alcuni casi, per l’incompetenza di chi lo sviluppa, problema in genere superabile con un’adeguata formazione professionale. In altri casi, però, il motivo non è la mancanza di competenza. Anche sviluppatori molto capaci producono a volte software non ottimale. Per fare più in fretta, per spendere meno tempo, perché non c’è più tempo. Per rilasciare prima, in tempo, la nuova versione del software.
Ogni volta che produciamo un software con dei problemi, che lo modifichiamo in un modo non ottimale, ad esempio facendo “copia e incolla” di porzioni di codice invece di riprogettare adeguatamente il programma, diminuiamo il livello di qualità del prodotto. Rendiamo più difficili, lunghe e costose le modifiche successive, che verranno anch’esse, probabilmente, fatte male. Così il software degrada ad ogni successiva modifica, e può accadere che anche prodotti inizialmente validi peggiorino ad ogni nuovo rilascio.
Questo è il debito tecnico. “Debito tecnico” è una metafora ideata da Ward Cunningham per far capire, sia agli sviluppatori che ai non addetti ai lavori, il costo economico che ha un intervento non ottimale sul software. Ogni volta che contraiamo un debito, ad esempio un mutuo (o il debito pubblico di una nazione), dobbiamo ripagarlo con gli interessi. Nel caso del software, ogni volta che effettuiamo un intervento inadeguato, scegliendo la strada più veloce anziché la migliore, abbassiamo la qualità e rendiamo più difficili e costosi gli interventi futuri.
Questo non significa che fare in fretta non sia necessario. A volte dobbiamo per forza scegliere la strada veloce anziché la migliore, perché non abbiamo alternative. Ma poi bisogna mettere le cose a posto, se si vuole evitare il peggio.
Deve essere installato e funzionare. Se lo è,
deve avere sufficienti prestazioni, ed essere sicuro. Se lo è,
deve essere usabile. Se lo è,
deve essere utile. Se lo è,
può avere successo.
Rappresentata come una piramide, questa scala di livelli di qualità del software è analoga alla piramide di Maslow sul soddisfacimento dei bisogni degli esseri umani.
Per Maslow, innanzitutto vanno soddisfatti i bisogni primari (cibo, temperatura ecc.). Soddisfatti questi, vanno soddisfatti i bisogni di sicurezza personale. Poi i bisogni legati alle relazioni e all’affettività. Poi i bisogni legati al riconoscimento e alla stima. Infine quelli legati alla realizzazione del proprio potenziale.
Se un livello precedente non viene soddisfatto, vengono compromessi i livelli successivi (ad esempio, se non si ha cibo sufficiente, l’attenzione alla sicurezza personale può diminuire).
L’analogia tra la scala dei bisogni di Maslow e i livelli di qualità del software è descritta in modo brillante da Gojko Adzic.