« C’est possible (2003) »

Histoire du développement du système d’exploitation Multics

• André Bensoussan, qui a développé le système d’exploitation Multics, était chargé des principales modifications du système de fichiers.
• Le gestionnaire VTOC est un sous-système qui assure le transfert des informations de fichiers entre le disque et la mémoire, la gestion d’un pool de tampons en mémoire partagée, ainsi que la gestion de l’espace d’information sur le disque.
• André a pris en charge la conception, l’implémentation et les tests du gestionnaire VTOC, en avançant dans le travail de conception à l’aide de nombreux diagrammes.

Processus de développement et réussite

• Tom Van Vleck, coordinateur du projet, s’inquiétait du calendrier, mais a été rassuré lorsqu’André a commencé à écrire le code.
• André écrivait le code au crayon plutôt que sur un terminal informatique, refusait même l’aide pour la frappe, et réalisait lui-même l’ensemble du travail.
• Au final, il a saisi sur le terminal le code proprement rédigé au crayon pour tenter une compilation ; après avoir corrigé quelques fautes de frappe, la compilation a réussi.
• Lors de l’intégration au système et des tests, le gestionnaire VTOC a fonctionné parfaitement dès le départ.

Les clés de la réussite d’André

• André a écrit un programme parfait en n’utilisant que le crayon comme outil.
• Le seul bug découvert dans le gestionnaire VTOC provenait d’une erreur de Tom Van Vleck, qui avait indiqué dans le mauvais ordre les appels à la procédure de gestion des erreurs.
• La manière de travailler d’André a été présentée comme une histoire sur le software engineering dans le numéro d’avril 1994 de IEEE Computer, puis mise à jour en novembre 2003.

L’avis de GN⁺

• L’histoire du développement du système d’exploitation Multics par André Bensoussan montre comment une conception rigoureuse et une forte concentration peuvent produire un résultat parfait.
• Comparée aux outils modernes et complexes de développement logiciel, cette méthode traditionnelle fondée uniquement sur le crayon et le papier souligne l’importance d’une approche fidèle aux fondamentaux.
• Cette histoire constitue un bon exemple rappelant l’importance d’un travail préparatoire minutieux et des tests dans le domaine du software engineering, et offre aussi une leçon importante pour la formation en ingénierie.

[GN⁺]

Avis Hacker News

• Résumé du premier commentaire :

  • Exigences claires : si les logiciels ont peu de bugs et sont rapides, c’est parce qu’ils reposent sur des exigences clairement définies. Aujourd’hui, on ne sait pas toujours précisément quoi construire, et l’approche « agile » entraîne des changements constants. Si on fournit aux développeurs une API claire et des critères bien définis, la plupart sont capables d’écrire du code efficace.

• Résumé du deuxième commentaire :

  • Les compétences des programmeurs soviétiques : d’après l’expérience de quelqu’un ayant travaillé avec des transfuges soviétiques, les programmeurs soviétiques étaient excellents parce que l’accès aux ordinateurs était très limité. Ils devaient programmer avec du papier et un crayon, ce qui les poussait à faire en sorte que ça fonctionne correctement dès le départ.

• Résumé du troisième commentaire :

  • L’importance d’un espace de travail personnel : en citant un commentaire du compte jrd259 dans un ancien fil Hacker News, ce point souligne l’importance d’un grand bureau et d’un espace de travail personnel sans notifications.

• Résumé du quatrième commentaire :

  • L’expérience de programmer sur papier : dans son enfance, quelqu’un a écrit chez son grand-père un programme Turbo Pascal à la machine à écrire, sans ordinateur, puis l’a exécuté plus tard sur un PC. Il raconte aussi avoir recopié sur papier une fonction d’addition binaire de son langage de programmation exotique Ziim pour y trouver et corriger un bug. L’idée mise en avant est qu’en limitant les méthodes « faciles », on produit un code mieux réfléchi.

• Résumé du cinquième commentaire :

  • La programmation autrefois : à la fin de l’ère du « gros fer », les programmeurs n’étaient guère différents des opérateurs de saisie. Les programmes étaient écrits sur papier, et le temps de calcul était coûteux et précieux. En cas de bug, il fallait attendre la prochaine exécution CPU programmée pour pouvoir corriger. Cela encourageait une approche prudente. Aujourd’hui, on développe les logiciels de manière itérative en déboguant dans un IDE.

• Résumé du sixième commentaire :

  • Le code écrit par André Bensoussan : un lien vers du code écrit par André Bensoussan est fourni.

• Résumé du septième commentaire :

  • La taille des logiciels d’autrefois : à l’époque, les logiciels étaient bien plus petits qu’aujourd’hui, et la plupart des projets se comptaient en mégaoctets, ce qui était trop volumineux pour être « gravé » dans un seul fichier.

• Résumé du huitième commentaire :

  • Les devoirs de programmation à l’école : selon l’expérience d’un ami, les devoirs de programmation étaient remis sur papier à l’école, et les résultats revenaient une semaine plus tard. Cette « semaine de compilation » avait une valeur pédagogique en forçant à tout vérifier deux fois.

• Résumé du neuvième commentaire :

  • L’absence d’agile/scrum : en réponse à la question de savoir comment André pouvait travailler ainsi, l’explication donnée est que les méthodologies de développement agile/scrum n’avaient pas encore été inventées.

• Résumé du dixième commentaire :

  • L’expérience de coder sur papier : à 14 ans, pendant un cours de programmation au lycée, quelqu’un écrivait la majeure partie de son code sur papier. Enfant pauvre dans un pays pauvre, il n’avait pas de PC à la maison, et les clones de ZX Spectrum de la salle informatique de l’école ne pouvaient pas exécuter le Turbo Pascal qu’il utilisait.