Il codice non testato non funziona!

Questa storia è una versione modificata di un messaggio che ho recentemente postato sul forum Multics su LinkedIn.

Avere i vostri cambiamenti "go live" molto rapidamente può essere un potente incentivo. Questa è la storia del primo bug che ho introdotto nel Multics, che era un importante sistema operativo che veniva creato al MIT alla fine degli anni '60 e all'inizio degli anni '70.

Ero una giovane matricola del MIT che era stata accettata nel progetto Multics. Mi sono offerta volontaria per aggiungere una funzione al comando dprint ("stampa demone") che metteva in coda le richieste per l'elaborazione del demone della stampante di linea. Uno dei manager mi ha chiesto di registrare il numero di copie nella richiesta, invece di aggiungere N richieste alla coda. Questo cambiamento avrebbe risolto una condizione di gara che comportava la cancellazione delle richieste di stampa completate. Ho apportato le modifiche e le ho testate in modo soddisfacente.

Le mie modifiche sono state presto installate e sono stato entusiasta di poter migliorare il sistema. Ma il mio brivido è stato di breve durata, perché ho presto risposto al telefono del mio ufficio e mi sono ritrovato ad ascoltare un utente arrabbiato che si lamentava del fatto che avevo rotto il suo programma. Sono tornato indietro e ho visto che non avevo notato, o testato, il punto di ingresso di subroutine nello stesso file sorgente. Certo, l'avevo rotto. L'ho aggiustato e la vita è andata avanti. Ma non ho mai dimenticato quella telefonata. Non sono ancora perfetto, ma quella voce irritata che risuona nella mia testa mi ha salvato da molti errori simili e disattenti nel corso degli anni.

L'aforisma che ho coniato da questo caso è "Il codice non testato non funziona".

Prova il tuo codice. Trova i tuoi bug, non farli trovare ad altri. Evita la voce irritata!