Cette histoire est une version éditée d'un message que j'ai récemment posté sur le forum Multics sur LinkedIn.
Le fait que vos changements soient mis en œuvre très rapidement peut être une puissante incitation. Voici l'histoire du premier bogue que j'ai introduit dans Multics, un système d'exploitation majeur créé au MIT à la fin des années 60 et au début des années 70.
J'étais un jeune étudiant de première année du 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 de l'imprimante de ligne. L'un des responsables m'a demandé d'enregistrer le nombre de copies dans la demande, au lieu d'ajouter N demandes dans la file d'attente. Ce changement résoudrait une condition de course impliquant la suppression des demandes d'impression complétées. J'ai apporté les modifications et les ai testées à ma satisfaction.
Mes modifications ont été rapidement installées et j'ai été ravi de pouvoir 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 je me suis retrouvé à écouter un utilisateur en colère se plaindre que j'avais cassé son programme. J'y suis retourné 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. Bien sûr, je l'avais cassé. 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 faire de nombreuses erreurs similaires et imprudentes au cours des années qui ont suivi.
L'aphorisme que j'ai inventé à partir de cette affaire est "Le code non testé ne fonctionne pas".
Testez votre code. Trouvez vos propres bogues ; ne les faites pas trouver par d'autres personnes. Évitez les voix de colère !
Entreprise