L’arrivo del TDD

Diversi anni fa arrivò il TDD, il Test Driven Development. L’idea di fondo era semplice: il numero di errori che un compilatore, anche il migliore, può trovare in un software è minuscolo rispetto ai problemi che emergono a runtime, quando il sistema viene davvero utilizzato.

La proposta del TDD era apparentemente banale: scrivere, oltre al codice applicativo, anche codice di test, cioè software che esegue automaticamente altro software per verificare che si comporti come previsto, e per intercettare bug prima che arrivino agli utenti reali.

Una pratica divisiva

Sembrava una rivoluzione tecnica sensata, e in effetti lo è stata, ma ha polarizzato la comunità degli sviluppatori molto più di tante altre pratiche: da una parte i sostenitori, convinti di aver trovato finalmente un modo per migliorare concretamente affidabilità e manutenibilità; dall’altra i detrattori, secondo cui i test, in pratica, rallentano lo sviluppo e aggiungono overhead.

Nel tempo, il settore è andato avanti dando ragione ai primi: sono cresciuti strumenti di analisi statica, metriche di qualità, pipeline automatiche. Oggi una copertura dei test intorno all’80% è considerata normale in molti contesti, e in alcuni ambiti rappresenta addirittura una soglia minima di accettabilità.

Eppure la polarizzazione non è mai scomparsa davvero.

La scorciatoia della velocity

Periodicamente riemerge l’idea per cui “tutta questa qualità” sarebbe un lusso, e la vera priorità sarebbe la velocity: consegnare più velocemente, rilasciare prima, aumentare il throughput del team.

Anche questa visione, presa in astratto, è ragionevole, ma il problema nasce quando si misura l’attività invece del progresso.

In nome della velocity e dell’agility vengono spesso giustificate pratiche poco compatibili con agilità e velocità reali. La forma più comune è: “Intanto partiamo, poi si vede.”

Partire senza ignorare l’incertezza

Ora, sia chiaro: non tutti i progetti sono avionica o software ferroviario, e non tutto richiede processi ultra-rigidi o formalismi pesanti. In molti casi è corretto partire prima di aver chiarito ogni singolo dettaglio.

“Partire”, però, non significa ignorare l’incertezza, al contrario: significa essere molto consapevoli di quale incertezza accettare e quale ridurre subito.

Le distinzioni che aiutano

La prima distinzione utile è capire cosa è già stabile e cosa è ancora ambiguo. Le parti stabili vanno protette, mentre quelle incerte vanno progettate per evolvere senza rompere il resto del sistema.

La seconda è individuare le ragioni per cui qualcosa non è chiaro, perché se a volte l’incertezza è inevitabile, altre volte deriva semplicemente da mancanza di analisi, di progettazione o di competenze adeguate.

Torniamo all’esempio dei test: esistono porzioni di codice difficili da testare, ma che possono diventare facili appena si adottano tecniche di progettazione migliori. In questo senso, il testing misura non solo la qualità del software ma anche quella dell’architettura.

Cosa si sceglie di misurare

La terza distinzione, forse la più importante, riguarda cosa si sceglie di misurare.

È possibile che un software senza test arrivi in produzione prima di uno ben testato ma, se poi consideriamo il tempo totale per ottenere un sistema davvero funzionante, includendo bug fixing, rework, regressioni, incidenti in produzione e rallentamenti evolutivi; il vantaggio apparente spesso svanisce.

Lo stesso vale per progettazione, analisi architetturale, riduzione del debito tecnico o validazione incrementale dei requisiti: tutte pratiche frequentemente accusate di “rallentare”, ma è un’accusa che regge solo se si considera l’attività immediata invece del risultato complessivo.

Se invece misuriamo:

• il budget reale necessario per arrivare a un sistema stabile,
• il tempo dal kickoff all’effettiva disponibilità per gli utenti,
• la capacità evolutiva del software nel tempo,
• il livello di soddisfazione di stakeholder e team tecnici,
• il costo del rework e delle decisioni sbagliate,

allora emerge qualcosa di interessante: far emergere le aree di incertezza e affrontarle in modo esplicito non rallenta il progetto ma, al contrario, è spesso il modo più veloce per ottenere un risultato sostenibile.

La vera velocity non è la quantità di attività prodotta nel breve periodo ma la velocità con cui un’organizzazione trasforma in modo affidabile un problema ambiguo in un sistema funzionante, mantenibile e utile.

Questo è il punto in cui l’ingegneria del software smette di essere produzione di codice e diventa gestione consapevole del rischio.