I clienti giapponesi richiedevano pochi scarti per milione, setto od otto al massimo, ed era un obiettivo difficile da raggiungere. Occorre controllare le materie prime, assicurarsi che il processo produttivo rispetti i parametri previsti, verificare che a tutti i passi si riesca ad intercettare il problema, che può essere sporadico, o cronico. 70 materie prime, e centinaia di attività richieste per la produzione, devono esser messe assieme in modo sapiente e ripetitivo dalle persone e macchinari coinvolti. Il problema è difficile, ma hai tutto sotto gli occhi, sottomano, addirittura sotto il naso perché alcuni odori ti dicono se alcuni processi stanno funzionando correttamente, o no.
Entriamo nel campo del software, dove non vedi milioni di righe di codice, non tocchi con mano le reti, le base dati, l’interfaccia utente, e certamente l’unico odore che puoi sentire, di bruciato, significa che il guaio è irreparabile. Questa lontananza dai nostri sensi rende difficile comprendere quanto sia difficile testare il software, fare in modo di produrre codice senza bachi, prevedere quanto ci mettiamo per sviluppare una nuova funzionalità. Come per i pneumatici, ancora di più per il software occorre orchestrare una serie di attori, di componenti fisici e virtuali, per arrivare ad un prodotto che faccia quanto richiesto in maniera affidabile, senza sorprese. Io promuovo quello che si chiama Behavior Driven Development (sviluppo software guidato dal comportamento richiesto, qui): mettendo assieme chi definisce le caratteristiche e le tempistiche richieste dall’applicativo, chi assicura che tutte le componenti riescano a comunicare tra loro in modo affidabile, chi scrive il codice, partiamo dal progettare il test che ci rivelerà se quel codice assolve le funzioni richieste, o no.
E qui entra un'altra, enorme differenza, rispetto ad un prodotto fisico come lo pneumatico. Vi aspettate di poter guidare quelle quattro ruote per 50.000 chilometri, per anni, senza rumori, vibrazioni, e senza cambiar nulla. È impensabile cambiare un ingrediente per render la gomma più aderente alla strada, a meno di cambiar pneumatici con un altro modello. Nel software invece, il prodotto viene cambiato di continuo, vuoi per nuove richieste, per completarne alcune che non erano state incluse nella release iniziale, per superare la concorrenza. In ogni istante pensiamo di avere copie identiche del software che girano nell’ambiente “di produzione”, in quello di test ed in quello di sviluppo, ma in effetti non è mai così. Quando entriamo nel dettaglio delle connessioni di rete, dell’allocazione dei processori, nell’uso delle risorse, nei runtime ed in tutte le variabili in gioco che danno fenomeni sporadici, capiamo che abbiamo tre copie diverse in gioco, e spesso dobbiamo testare in produzione, l’equivalente di un’operazione a cuore aperto: un errore a blocchi tutto. Per chi volesse approfondire e farsi una risata, qui.
Quanto sopra significa che per produrre software in modo affidabile, nonostante i nostri cinque sensi non consentano di vedere e sentire tutti gli strumenti ed i suonatori, e pure lo spartito non sia sempre corretto, dobbiamo lavorare come in un orchestra e prenderci il tempo necessario per le prove prima della performance.
