1 Commento

Errare humanum, programmare diabolicum

Codice rosso

di

thumbnail

14

dic

2012

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?




Andrea C. Granata (@andreacgranata) ha pigiato i primi tasti su un bianco VIC20 quando ancora Internet era in fasce. Un po’ sistemista un po’ sviluppatore, ha una passione per FreeBSD, programmazione in Ruby, metodologie Agile e infrastrutture cloud. Si occupa di Enterprise Architecture e di DevOps per una delle più importanti banche italiane. Nel tempo libero si divide tra la passione per la cucina, il pattinaggio di figura e i viaggi in Oriente.

Letto 5.797 volte | Tag: , , , , , , ,

Un commento

  1. Paolo

    Una delle poche cose certe dell’informatica è che non è possibile, per sistemi di una complessità non minima, ovvero per sistemi abbastanza complessi da avere una qualche utilità pratica, effettuare una verifica esaustiva della funzionalità del software. Per ovviare a questo problema si impiegano diverse tecniche che, di norma, sono in grado di prevenire problemi gravi ma che falliscono miseramente quando i sistemi complessi non sono analizzati e scomposti nel migliore dei modi a monte della fase di scrittura del software. Sostanzialmente, se è ragionevole prevedere che l’esperienza e la buona pratica di programmazione, la ridondanza ed altre tecniche comunemente usate in ambiti critici possano prevenire malfunzionamenti causati, ad esempio, dal roll’up di un contatore, è difficile per non dire impossibile prevenire guasti causati da una eccessiva complessità fra le interfaccie dei moduli, da una scomposizione in moduli ed oggetti non adeguata alla realtà.
    Purtroppo gli errori a livello di analisi vengono sottovalutati nelle procedure di accreditamento del software e sono, di norma, alla radice dei malfunzionamenti più catastrofici.
    Nella mia esperienza, e sono trent’anni che scrivo software per macchine industriali e medicali, la maggior parte dei problemi catastrofici nasce da fenomeni di sincronizzazione fra oggetti/task o fra un oggetto/task e l’operatore.
    Questi fenomeni (tipico esempio il therac 25 sopra citato) sono più rari se si mantiene una corrispondenza fra il fenomeno controllato e la sua scomposizione in task ed oggetti. Resta il fatto che ho visto sistemi medicali complessi, in grado di arrecare danni gravi ad un paziente ed agli operatori, azionati da software di grande complessità, privi di una analisi funzionale decente, dove compiti banali e monolitici venivano, senza nessun motivo logico, spezzettati in più oggetti spesso situati su processori di versi. Chiaro che in sistemi di questo tipo parlare di sicurezza è un non senso, il software potrà anche essere di alta qualità, ma senza una solida base di analisi il sistema non potrà mai essere affidabile.
    Ciao, Paolo.

Lascia il tuo commento