Il software può avere un impatto terrificante sulla vita delle persone reali. Non si tratta solo di un'astrazione relegata a un ambiente isolato. Quando scrivo codice, non è solo una questione tra me, il codice, il sistema operativo e il database. La faccenda è molto più complessa. L'impatto di quello che faccio quando sviluppo va molto al di là di questo e permea la vita delle persone.

Questa è la conclusione, per nulla banale, di un giovane progettista americano, Daniel Read, che giudica con maturità e distacco la sua prima esperienza lavorativa: viene assunto da una piccola società, che è in procinto di rilasciare la prima versione del suo nuovo software; da subito è coinvolto nella fase di duplicazione di floppy disk, scrittura di indirizzi sulle buste, confezionamento della documentazione. Poi il materiale, un migliaio di copie, viene finalmente spedito.

L'avvenuta ricezione da parte dei clienti è chiara dal momento che il telefono della società comincia a suonare. E non smette più di suonare: disastro totale! Molti non riescono nemmeno a finire l'installazione, e quelli che ci riescono sono meno contenti dei primi. Ci sono bug a non finire: calcoli errati, voci che si spostano da un ordine all'altro, ordini che spariscono completamente, rapporti impossibili da stampare, indici rovinati, menu incomprensibili, messaggi d'errore dal significato oscuro quasi dovunque, crash continui e via di questo passo. Alla fine il telefono viene staccato e attivata la segreteria telefonica.

Il tutto poi si risolve, ma con un enorme impegno da parte di tutti, che lavorano notte e giorno nei mesi successivi per correggere gli errori e distribuire maintenance release gratuite. Di chi è stata la colpa? Per Daniel Read la risposta è evidente: del codice.

Ma chi ha pagato le conseguenze di quell'errore? Daniel Read azzarda un elenco delle persone che hanno subito gravi danni da quell'esperienza: ovviamente le centinaia di clienti che dovettero far le ore piccole per cercare di risolvere quei guai; i loro familiari costretti a privarsi della presenza dei propri cari costretti al lavoro; i dipendenti delle società clienti che soffrirono lo stress dei loro capi; i proprietari dell'azienda di Read, che pur non essendo coinvolti nell'attività quotidiana, furono fortemente danneggiati nella reputazione e nel conto corrente; tutti coloro che avevano consigliato la società di Read a terzi, che fecero una pessima figura; tutti i dipendenti della società, condannati a portare sulle spalle il peso di quel fallimento; il programmatore che aveva sbagliato e tutti gli altri che furono costretti a correggere i bug. Almeno un migliaio di persone per un solo codice.

A chi tra i lettori avesse da obiettare che il codice sia solo un ingranaggio del meccanismo produttivo e che la responsabilità fosse da addossare interamente all'azienda, la quale non aveva evidentemente messo in atto le procedure di testing e verifica sul proprio prodotto, Read dà una risposta: "Che la responsabilità sia anche della società è vero, ma ciò non assolve lo sviluppatore. Lui è l'unico che può scrivere codice. E un pessimo codice rimane un pessimo codice."

Secondo Read, quando programmiamo non dobbiamo mai dimenticare le persone che utilizzeranno l'applicazione e di quelle che la supporteranno quando noi ce ne saremo andati.