Risparmia 100€ con il codice BIGADATA100

Big Data Executive | Milano | sabato 30 novembre

Iscriviti al corso sui Big Data
Home
Codice rosso

14 Dicembre 2012

Codice rosso

di

Prima o poi qualcuno porrà la problematica della qualità del software. Speriamo che siano le organizzazioni giuste.

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?

L'autore

  • Andrea C. Granata
    Andrea C. Granata vanta oltre 25 anni di esperienza nel mondo dello sviluppo software. Ha fondato la sua prima startup nel 1996 e nel corso degli anni si è specializzato in soluzioni per l'editoria e il settore bancario. Nel 2015 è entrato a far parte di Banca Mediolanum come Head of DevOps, ruolo che oggi ricopre per LuminorGroup.

Vuoi rimanere aggiornato?
Iscriviti alla nostra newletter

Novità, promozioni e approfondimenti per imparare sempre qualcosa di nuovo

Gli argomenti che mi interessano:
Iscrivendomi dichiaro di aver preso visione dell’Informativa fornita ai sensi dell'art. 13 e 14 del Regolamento Europeo EU 679/2016.