Cette histoire est une version éditée d'un message que j'ai récemment publié sur le forum Multics sur LinkedIn.
Le fait que vos modifications soient mises en œuvre très rapidement peut constituer une motivation puissante. Voici l'histoire du premier bug que j'ai introduit dans Multics, un système d'exploitation majeur développé au MIT à la fin des années 1960 et au début des années 1970.
J'étais un jeune étudiant de première année au MIT qui avait été accepté dans le projet Multics. Je me suis porté volontaire pour ajouter une fonctionnalité à la commande dprint (« daemon print ») qui mettait en file d'attente les demandes à traiter par le démon d'impression en ligne. L'un des responsables m'a demandé d'enregistrer le nombre de copies dans la demande, au lieu d'ajouter N demandes à la file d'attente. Cette modification permettrait de résoudre un problème de concurrence lié à la suppression des demandes d'impression terminées. J'ai apporté les modifications et les ai testées à ma satisfaction.
Mes modifications ont été rapidement installées et j'étais ravi d'avoir pu améliorer le système. Mais mon enthousiasme a été de courte durée, car j'ai rapidement répondu au téléphone de mon bureau et me suis retrouvé à écouter un utilisateur furieux se plaindre que j'avais endommagé son programme. Je suis retourné vérifier et j'ai constaté que je n'avais pas remarqué, ni testé, le point d'entrée du sous-programme dans le même fichier source. Effectivement, je l'avais endommagé. Je l'ai réparé et la vie a continué. Mais je n'ai jamais oublié cet appel téléphonique. Je ne suis toujours pas parfait, mais cette voix furieuse qui résonne dans ma tête m'a évité de commettre de nombreuses erreurs similaires par négligence au fil des ans.
L'aphorisme que j'ai tiré de ce cas est « Un code non testé ne fonctionne pas ».
Testez votre code. Trouvez vos propres bugs ; ne laissez pas les autres les trouver. Évitez les voix furieuses !