Quando testare un codice è questione di vita o di morte

Il programmatore medio in genere non commenta meticolosamente il proprio codice né tantomeno esegue uno sfacelo di passaggi per la verifica del codice sorgente. Il che va benissimo, visto che il programmatore medio di solito non lavora su dei software per aerei con motori a jet, impianti nucleari o chirurghi robotici. Ma qualcuno ci lavora—e ci sono ottime possibilità che la tua vita sia passata anche dalle loro mani non troppo tempo fa.

Come sai se stanno facendo bene il loro lavoro?

Non lo puoi sapere. Ti fidi. Ciò ci permette di chiederci: Come viene testato questo tipo di codice? Più precisamente, è stato un breve articolo scritto da Gene Spafford, professore di informatica alla Purdue University, che ci ha fatto davvero porre questa domanda. Parla di un anedotto riguardante l'origine delle interfacce di comando elettroniche degli aerei a fine anni '80. Oggi per noi non sono gran cosa, ma ai tempi si trattava di un grosso salto tecnologico: si toglieva il controllo diretto ai piloti e lo si sub-appaltava a delle interfacce che traducevano gli input dei piloti in input meccanici. Da allora la sicurezza di un aeroplano è in mano ad un computer.

E questo fatto ha reso fondamentale il ruolo di chi sta dietro alla gestione di questi computer.

Scrive Spafford:

Così facendo i programmatori dei Boeing avevano un'ulteriore motivazione per fare bene il loro lavoro, visto che ci andavano di mezzo anche le loro vite sin dal primo volo. Non c'era spazio per riparazioni d'urgenza a 9.000 metri di altitudine—poteva solo funzionare. Con chi ti sentiresti più tranquillo? Con chi ha provato la sua stessa medicina, o con chi la medicina l'ha fatta passare per centinaia di test senza provarla?

A me andrebbero bene entrambi, devo dire, ma chiedersi come siano stati testati questi software è anche parecchio interessante. Una discussione del 2011 su Stack Exchange ha fornito diversi retroscena su questo processo e sulla sua evoluzione. L'approccio di Boeing è finito fuori moda, o almeno la maggior parte di questo approccio, secondo Uri Dekel, un ingegnere software di Google.

"Ci si sta muovendo sempre più verso la verifica formale del codice, piuttosto che affidarsi a test funzionali dalle condizioni casuali," scrive. "Agenzie governative come la NASA e alcuni dipartimenti di difesa stanno spendendo sempre di più per queste tecnologie. Sono ancora un dito nel culo per il programmatore medio, ma sono sempre più efficaci per il testing di sistemi importanti su cui non si può sbagliare."

Scott Whitlock, un ingegnere software che si occupa della manutenzione della libreria per l'automazione domotica FluentDwelling approfondisce il discorso, spiegando i requisiti per i sistema di sicurezza, sistemi utilizzati in applicazioni industriali sfruttati per monitorare i segnali di allerta degli equipaggiamenti, di modo da spegnerli in sicurezza se necessario. I sistemi includono, secondo Whitlock, "Due processori ridondanti, recuperati spesso da venditori diversi e muniti di design di progettazione diverso. Il software che permette loro di funzionare deve essere sviluppato da due team diversi che lavorano in condizioni isolate. L'output restituito dai due processori deve essere identico, altrimenti i test di sicurezza non risulteranno superati.

"Oggi, dopo aver progettato il tuo sistema di sicurezza, la logica che ti guida nelle fasi di testing può essere molto istintiva," aggiunge Whitelock. "I programmatori spesso finiscono col mandare in crash macchine facendo migliaia di dollari di danni, a perlomeno poi nessuno si farà male."

E per navicelle spaziali munite di equipaggio? Per quanto riguarda le criticità, una navicella è paragonabile a un aereo di linea incrociato con un sistema di supporto vitale incrociato con il più difficile problema matematico presente in aeronautica.

"Questo software non va mai in crash," si presenta così Fast Company di Charles Fishman in "They Write the Right Stuff." "Non ha mai bisogno di essere riavviato. È un software privo di bug. È perfetto, quanto di più perfetto che l'uomo possa mai creare. Considerate queste statistiche: le ultime tre versioni del programma avevano solamente un errore ciascuna—e ognuna era fatta di 420,000 righe di codice. Le ultime 11 versioni avevano un totale di 17 errori. I programmi commerciali di simile complessità ne avrebbero normalmente 5,000, di erri."

Come fanno i programmatori NASA a raggiungere questi risultati. Principalmente perché è il loro lavoro. Il più piccolo dei bug potrebbe mettere a rischio miliardi di dollari e numerosi vite. Il tutto sotto gli occhi del pubblico del mondo intero.

"Prima di ogni volo, Ted Keller, il senior technical manager dell'equipaggio a bordo, vola fino in Florida per firmare un documento che certifica che il software non metterà in pericolo lo shuttle," spiega Fishman. "Se Keller non può andare, vi è un ordine ben preciso per decidere chi è il prossimo autorizzato a firmare quel documento."

Per quanto riguarda il codice, la sua perfezione è il prodotto di praticamente l'opposto di ciò che normalmente fa un programmatore. La creatività, nel gruppo per lo shuttle, era una pratica non incoraggiata, i turni erano dalle nove alle cinque del pomeriggio; i programmatori guru e le superstar non erano figure tollerate; più di metà del team era costituto da donne; il debugging non era una pratica troppo prevista, visto che gli errori non erano nei piani. La programmazione non era un prodotto dei coder o degli ingegneri, ma del Flusso di Lavoro.

"Il processo è estremamente pervasivo, è responsabile di qualunque tipo di errore," ha scritto Fishman, "se c'è un problema nel software, deve esserci qualcosa di sbagliato nel modo con cui è stato scritto, e quel qualcosa può essere corretto." Il software è perfetto e non c'è margine di errore.

Inoltre:

Quindi, cosa ne pensi caro mio futuro astronauta? Preferisci il programmatore che ha volato sull'aereo col suo software installato, o il team di testuggini NASA?