Critique de livre: The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition

The Mythical Man-Month (MM-M) de Frederick P. Brooks, Jr. est l'un des livres les plus célèbres de toute la littérature sur le développement logiciel et est sans doute LE livre le plus célèbre sur la gestion du développement logiciel. Il existe déjà d'innombrables critiques de cette classe, mais je la passe en revue à nouveau dans cet article pour les développeurs de logiciels qui ne l'ont pas lu et qui veulent un petit aperçu de ce qu'il y a à y aimer. Après tout, c'est le titre n ° 1 de PC World dans la liste des dix meilleurs livres informatiques à ne jamais admettre que vous n'avez pas lu. Le titre complet de l'édition que je passe en revue dans cet article est The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition.

L '"édition anniversaire" de The Mythical Man-Month (publiée en 1995) ajoute un contenu significatif au-delà de ce qui a été publié dans l'édition originale en 1975. L' "édition anniversaire" contient le livre original dans sa forme originale (bien qu'avec l'inclusion des corrections ajoutées dans la réimpression de 1982) et ajoute quatre nouveaux chapitres. Les quinze premiers chapitres de l'édition anniversaire sont les chapitres du livre original. Les chapitres ajoutés incluent l'article séparé mais tout aussi célèbre de Brooks, IFIPS (1986) / IEEE Computer Magazine (1987), No Silver Bullet: Essence and Accidents of Software Engineering et un suivi appelé No Silver Bullet ReFired. Les chapitres 18 et 19 de l'édition anniversaire se concentrent sur l'auto-perspective de Brooks en 1995 sur ce qu'il a écrit en 1975.Brooks souligne ce qu'il s'est trompé et ce qu'il a eu raison (il y a beaucoup plus de cas de ce dernier que de l'ancien).

Il existe de nombreuses critiques de The Mythical Man-Month qui incluent une couverture exhaustive des sujets et des citations de ce livre (article Wikipédia, résumé de The Mythical Man-Month de Bernard I.Ng, Quelques aperçus du Mois de l'homme mythique à partir du chapitre 11, Mythical Man-Month - Extraits I, The Mythical Man-Month - Extraits II, The Mythical Man-Month Lecture, et Review / Summary of The Mythical Man-Month, par exemple). Plutôt que de répéter un aperçu du contenu du livre dans son ensemble, je me concentre dans cet article sur quelques points clés et à la lumière de certaines meilleures pratiques et idéologies logicielles modernes.

Chapitre 19 ("Propositions du mois de l'homme mythique: True or False? ") De l '" Anniversary Edition "plaira particulièrement au lecteur impatient ou qui n'a pas le temps de lire l'intégralité du livre, mais qui souhaite avoir une vue d'ensemble des affirmations de Brooks. Parce que Brooks utilise ce chapitre pour présenter «l'essence du livre de 1975» sous forme de «plan», les affirmations de Brooks («faits et généralisations de type règle empirique tirées de l'expérience») tirées de son livre original sont présentées sous une «forme crue» (environ 20 pages). La présence de ce chapitre dans "Anniversary Edition" est une autre raison pour laquelle je ne décompose pas le livre chapitre par chapitre ici. Ce chapitre fait plus que simplement résumer les affirmations du livre original; il comprend également certaines dess Commentaires de 1995 basés sur 20 années supplémentaires d'observation et le bénéfice du recul.

Dans son article The Mythical Man Month: Book Review, Mark Needham conclut sa critique de ce livre par la déclaration suivante: «J'ai vraiment aimé lire ce livre et voir à quel point beaucoup d'idées dans les méthodologies plus modernes étaient déjà connues dans les années 1980 et ne sont pas essentiellement de nouvelles idées. " Je suis entièrement d'accord avec cette déclaration, bien que la vérité en soit peut-être encore plus stupéfiante: il s'agissait d'observations dans un livre publié en 1975 basé sur les expériences de Brooks travaillant sur le développement d'OS / 360 au milieu des années 1960 et sur la fin des années 1960s. En d'autres termes, certaines des choses que nous pourrions penser être «nouvelles» ou «à la mode» aujourd'hui existent et sont connues depuis 45 ans ou plus! En passant, cela me rappelle une présentation d'Alan M. Davis au Denver Java Users Group ("What's New About New Methods of Software Development?") Fin 2006, dans laquelle il a montré combien de "nouvelles" méthodologies et Les tactiques d'aujourd'hui ont des prédécesseurs très similaires dans les années passées et comment nous semblons passer de l'un à l'autre au fil des décennies.

Les points suivants soulevés par Brooks sont particulièrement intéressants lorsque l'on garde à l'esprit que ce livre a été publié en 1975 sur la base d'expériences du milieu à la fin des années 1960 (ces citations sont tirées du résumé du chapitre 19 mais sont basés sur le texte de l'édition de 1975):

  • "Les très bons programmeurs professionnels sont dix fois plus productifs que les pauvres ..." [savoir-faire]
  • "" Une petite équipe pointue est préférable - le moins d'esprit possible. "[Agile]
  • "La correction d'un défaut a une chance substantielle (20 à 50 pour cent) d'en introduire un autre. Après chaque correction, il faut exécuter la banque entière de cas de test précédemment exécutés sur un système pour s'assurer qu'il n'a pas été endommagé de manière obscure." [les tests de régression]
  • «Cela vaut la peine de créer de nombreux échafaudages de débogage et de tester le code, peut-être même 50% de plus que le produit en cours de débogage.» [test unitaire]
  • "Pour maintenir la documentation à jour, il est essentiel qu'elle soit incorporée dans le programme source, plutôt que conservée en tant que document séparé ... même la syntaxe d'un langage de haut niveau n'indique aucun but." [Principe DRY]

Il y a beaucoup plus d'observations dans The Mythical Man-Month qui démontrent que Brooks et d'autres développeurs de l'époque comprenaient bon nombre des mêmes bases du développement logiciel que nous comprenons (et parfois «découvrons» à nouveau) aujourd'hui. Beaucoup d'entre eux sont plus connus et sont mentionnés dans d'autres critiques.Je ne les énumère donc pas ici, à l'exception de ces citations incontournables:

  • "Plus de projets logiciels ont mal tourné par manque de temps calendaire que pour toutes les autres causes combinées."
  • Loi de Brooke: "L'ajout de main-d'œuvre à un projet logiciel tardif le rend plus tardif."
  • "Par conséquent, le mois-homme comme unité de mesure de la taille d'un travail est un mythe dangereux et trompeur."

L'une des sections que j'ai trouvées particulièrement opportunes (en particulier pour un livre de 1975 en 2011) était la couverture par Brooks de la façon dont un architecte logiciel peut influencer la mise en œuvre. Cela peut être particulièrement sensible lorsque la vision de l'architecte n'est pas mise en œuvre par le développeur de la manière souhaitée par l'architecte. Les conseils de Brooks semblent très pratiques. Il déclare que l'architecte doit accepter le fait que la personne qui met en œuvre le code a «la responsabilité créative» de cette implémentation. Il conseille en outre que l'architecte doit toujours avoir une idée de la mise en œuvre de l'un de ses projets, mais doit en même temps être prêt à accepter une approche alternative tout aussi bonne proposée par la personne qui met en œuvre le code. Brooks recommande en outre que l'architecte fasse toutes les suggestions concernant la mise en œuvre "tranquillement et en privé, «soyez« prêt à renoncer au crédit »et soyez prêt à écouter les« suggestions d'améliorations de l'architecture »de l'implémenteur. Cela me semble être un bon conseil basé sur mes expériences des deux côtés de cette relation.

Dans l'article de 2005 cité souvent, rarement suivi, Brooks déclare:

Le livre est vraiment plus sur la gestion que sur la technologie. La technologie a énormément changé, de sorte que certains des anciens chapitres sont totalement désynchronisés. D'un autre côté, les gens n'ont pas beaucoup changé. C'est pourquoi Homère, Shakespeare et la Bible sont toujours pertinents, car ils traitent tous de la nature humaine. Je pense que cela fait partie de l'explication de ce livre: les problèmes de gestion des personnes en équipe n'ont pas changé, bien que le support dans lequel les gens conçoivent et les outils qu'ils utilisent ont. Certaines personnes ont appelé le livre la «bible du génie logiciel». Je suis d'accord avec cela sur un point: c'est-à-dire que tout le monde le cite, certaines personnes le lisent et quelques personnes s'en foutent.

Les concepts contenus dans cette citation peuvent être la chose la plus importante à transmettre dans une revue de The Mythical Man-Month. L'attrait du livre est sa couverture et sa concentration sur la gestion des personnes. Cela est resté intemporel et inchangé au fil des décennies. Les technologies ont définitivement changé de manière significative et c'est peut-être le plus gros inconvénient de ce livre. Les exemples de Brooks basés sur des produits, des outils et des langages spécifiques en 1975 étaient certainement plus illustratifs à l'époque qu'ils ne le sont aujourd'hui pour le lecteur typique. Par exemple, son livre de 1975 appelle PL / I «le seul candidat raisonnable pour la programmation système aujourd'hui». Parfois, une partie de la lecture peut être un peu plus difficile en raison du manque d'expérience directe avec les produits mentionnés par Brooks. Cependant, dans la plupart des cas, ce n'est pas vraiment un obstacle à la fin parce que l'élément humain est au centre du livre et cela est pratiquement inchangé même maintenant. Au chapitre 19 de l'édition anniversaire,Brooks réfléchit à la popularité continue de son livre et déclare: "dans la mesure oùLe MM-M concerne les personnes et les équipes, l'obsolescence devrait être lente. "

Le Mythical Man-Month concerne en fait de très grands projets de développement de logiciels d'entreprise. Il est important de garder cela à l'esprit lors de la lecture de choses qui peuvent sembler évidentes à quelqu'un qui travaille sur un petit projet. La dernière partie de la citation ci-dessus est célèbre: «Certaines personnes ont appelé le livre la« bible du génie logiciel ». Je serais d'accord avec cela sur un point: c'est-à-dire que tout le monde le cite, certains le lisent, et quelques personnes le suivent. " Le livre de Brooks est rempli de références bibliques et il connaît évidemment la Sainte Bible. Malheureusement, la citation de Brooks "tout le monde la cite, certaines personnes la lisent, et quelques personnes la suivent" n'est que trop vraie aujourd'hui. Nous continuerons à le lire, mais ce serait bien de faire plus pour changer les choses dans les projets de développement de logiciels à grande échelle.

Certaines personnes pensent que le mois de l'homme mythiqueest défaitiste et même déprimant. Je n'ai pas le même sentiment en le lisant. Je pense plutôt que cela nous rappelle que certains comportements sont préjudiciables et dysfonctionnels. Cela nous rappelle également que nous ne devrions pas attendre la «prochaine grande chose», mais plutôt continuer à améliorer notre métier du mieux que nous pouvons. De nombreux conseils et suggestions pratiques sont fournis. Brooks aime évidemment être dans le domaine du développement de logiciels et cela est montré encore et encore dans son livre. Brooks conclut le livre "Epilogue: Fifty Years of Wonder, Excitation, and Joy", en parlant de la façon dont il était capable de "lire tous les journaux et actes de conférence", mais a finalement dû renoncer à des intérêts spécifiques un par un. les connaissances ont explosé. Il conclut: «Trop d’intérêts, trop d’opportunités d’apprentissage passionnantes,recherche et réflexion. Quelle merveilleuse situation! Non seulement la fin n'est pas en vue, mais le rythme ne ralentit pas. Nous avons de nombreuses joies futures. "Je suis tout à fait d'accord.

Publication originale disponible sur //marxsoftware.blogspot.com/ (Inspiré par des événements réels)

Cette histoire, "Critique de livre: Le mois de l'homme mythique: Essais sur le génie logiciel, édition anniversaire" a été initialement publiée par JavaWorld.