Fred Brooks est décédé le mois dernier à l'âge de 91 ans. Grâce à son best-seller sur la gestion du développement logiciel, The Mythical Man-Month Essays on Software Engineering, il est devenu une légende de la programmation et de la gestion.
Au fil des décennies, j'ai rencontré de nombreux leaders technologiques, mais peu étaient aussi impressionnants que Brooks. Bien que je l'ai vu à plusieurs reprises lors d'événements, je ne lui ai parlé qu'une seule fois lorsqu'il était directeur du département d'informatique de l'Université de Caroline du Nord.
Certains leaders technologiques, comme Steve Jobs, montrent leur génie comme une nova. D'autres, comme Brooks, sont calmes, spirituels et tout aussi brillants à leur manière.
Même sans le livre, Brooks serait célèbre dans l'histoire de l'informatique pour être l'un des leaders dans le développement d'un système d'exploitation pouvant être utilisé sur plus d'une architecture informatique : OS/360.IBM.
Assembler 360 s'est avéré être mon premier langage de programmation. Avertissement juste : le langage à la première personne ne doit pas être IBM 360 Assembler.
Quant au 360 Job Control Language (JCL), j'ai appris en même temps que Brooks lui-même l'appelait "le pire langage de programmation informatique jamais conçu par quiconque, n'importe où". Je dirai simplement qu'il y avait des "raisons" pour lesquelles je suis passé des ordinateurs centraux aux mini-ordinateurs Unix.
Personnellement, cependant, Brooks a noté: "La décision la plus importante que j'ai prise a été de changer la série IBM 360 d'un octet 6 bits à un octet 8 bits, ce qui permettait l'utilisation de lettres minuscules. Ce changement s'est répandu dans toutes les parties".
Si c'est vrai. Les architectures informatiques 8 bits, 16 bits, 32 bits et 64 bits avec lesquelles nous avons tous grandi ont commencé avec Brooks.
Heck, le mot même "architecture" pour les puces informatiques et les conceptions vient de lui.
Mais ce dont la plupart d'entre nous se souviennent, c'est de son livre, avec ses déclarations de gestion concises. Maintenant, si seulement nous les utilisions davantage dans nos bureaux !
Commençons par la plus connue d'entre elles : la loi de Brooks : "Ajouter de la main-d'œuvre à un projet logiciel en retard le rend en retard."
Maintes et maintes fois, je vois des entreprises gâcher cela.
Le plus souvent de nos jours, cette erreur se manifeste en insistant pour que, oh, disons simplement, tous les développeurs se présentent au bureau le vendredi après-midi pour justifier leur travail et travailler sur un sprint. Oui, en fait, je pense à Elon Musk et Twitter.
Mais il n'y a pas que Musk. Si dans votre entreprise, vous finissez toujours par consacrer beaucoup d'heures supplémentaires à la fin d'un projet pour les mener à bien, vous vous trompez. Bien sûr, parfois c'est nécessaire; mais si c'est devenu une habitude, vous avez un problème de gestion.
Un brooksisme connexe est que "neuf femmes ne peuvent pas avoir de bébé en un mois". Ou, en prenant le relais de Musk, vous ne pouvez pas non plus faire appel à neuf programmeurs de systèmes de véhicules Tesla et créer une nouvelle fonctionnalité de médias sociaux en un mois. Ou trois mois, ou neuf mois, d'ailleurs.
Une autre question connexe est : « Comment un grand projet logiciel peut-il avoir un an de retard ? Réponse : un jour à la fois ! La solution consiste à s'assurer que les jalons individuels sont atteints à chaque niveau de gestion.
Brooks a également soutenu l'idée de petites équipes logicielles étroitement gérées qui peuvent éviter la surcharge de fonctionnalités et prendre leur temps.
Après tout, a également déclaré Brooks, "un bon logiciel, comme une bonne nourriture, prend du temps à produire".
Maintenant, certaines personnes diraient que l'open source a réfuté cela. Dans le manifeste open source The Cathedral and the Bazaar , Brooks a plaidé pour un style «cathédrale». En revanche, les développeurs Linux et open source peu organisés ont publié des mises à jour logicielles tôt et souvent.
Mais est-ce vraiment le cas?
Si vous regardez de plus près comment Linux est développé, vous verrez beaucoup de développeurs. Mais ils sont dirigés par un groupe beaucoup plus restreint de fonctionnaires dirigé par Linus Torvalds. Les ajouts de code eux-mêmes consistent en de nombreux petits changements.
Des changements importants, comme l'ajout de Rust à Linux ou WireGuard VPN, prennent des années à se produire.
Je pense qu'il convient de noter qu'à l'époque médiévale, les bazars se tenaient souvent sur le terrain de la cathédrale.
Brooks nous a également avertis de faire attention aux balles en argent.
"Il n'y a pas un seul développement, que ce soit dans la technologie ou la technique de gestion, qui promet à lui seul une amélioration d'un ordre de grandeur en une décennie en termes de productivité, de fiabilité, de simplicité." En bref, si quelqu'un de votre équipe promet que votre dernière idée, découverte ou invention « changera le monde ». Ne les croyez pas
Bien sûr, il y a des développements qui changent le monde.
Plus récemment, on pense au cloud computing, aux Docker/conteneurs et à l'edge computing. Mais rien de tout cela n'est arrivé aussi vite qu'on pourrait le penser.
Ils ont tous mis des années à mûrir et à devenir significatifs. Je veux dire, même si le succès apparemment soudain de Docker vous a peut-être surpris, sa technologie de conteneur remonte à 2000 et aux prisons de FreeBSD.
Enfin, DevOps, la grande tendance de développement actuelle, doit également beaucoup aux travaux de Brooks.
Il croyait fermement que tout le monde communiquait sur un projet. (C'est le besoin d'une communication efficace qui rend impossible la résolution des problèmes logiciels en y consacrant plus d'heures de travail.)
Bien sûr, nous le faisons souvent maintenant dans Git et avec des outils CI/CD, mais les communications aujourd'hui, comme elles l'étaient au début des années 60, sont toujours essentielles au succès de la programmation et des projets commerciaux.
Et réussir, c'est ce que voulait Brooks.
Copyright © 2022 IDG Communications, Inc.