Codice rosso

Nel mio recente pezzo sull’arte del programmare giungevo alla conclusione che esistono software scritti talmente male che si riesce a percepire chiaramente l’incuria di chi li ha programmati. Lo scopo era evidenziare la contrapposizione tra funzionale e disfunzionale, bello e brutto, quasi a introdurre una sorta di estetica – in senso filosofico – del software.

L’articolo di Robert Martin dal titolo Dopo il disastro mi spinge a superare l’approccio estetico e a spostare l’attenzione verso il dominio dell’etica:

Più prima che poi, accadrà qualcosa. Migliaia di persone moriranno. E sarà colpa di un pezzo di codice fallato, scritto da qualche povero sciocco sotto una pressione infernale a causa di scadenze impossibili. Forse sarà un disastro aereo, o il naufragio di una nave da crociera. Forse un’esplosione in una fabbrica, forse il deragliamento di un treno carico di sostanze tossiche. Forse sarà un semplice errore di procedura in un laboratorio medico che permetterà l’uso improprio di una fiala di vaiolo o Ebola.

Martin probabilmente esagera, preso com’è dalla foga di esternare il suo terrore che un evento catastrofico mini la libertà degli sviluppatori e imponga una stretta regolamentazione da parte dello Stato in materia di qualità del software.

Quello che però non ci dice è che alcuni eventi disastrosi si sono già verificati.

L’esplosione di Ariane 5 non ha provocato vittime, ma ha generato un danno stimato in trecentosettanta milioni di dollari e probabilmente rientra nella lista dei dieci bug software più costosi di sempre. In altri casi – come quello del Therac25 – i danni sono andati ben oltre il mero denaro.

Negli ultimi anni sono stati compiuti importanti progressi in industrie come quella aerospaziale e aeronautica, in cui il software viene sottoposto a verifica formale, ma questo non basta a farci dormire sonni tranquilli, visto che nella maggior parte dei casi non vengono nemmeno scritti test automatici per verificare le parti più critiche dei software.

Martin conclude il suo pezzo con un appello agli sviluppatori, invitandoli ad agire prima che sia troppo tardi. Ma siamo sicuri che sia sufficiente delegare questo tipo di controllo alla buona volontà dei singoli? In un mondo in cui si sente la necessità di legiferare sulla qualità dei cetrioli, è possibile che non si faccia nulla per garantire quella del software?