Combien du Mythe du Mois Homme s'applique encore?

Question

Ce livre a été écrit à l'époque des systèmes de partage du temps, de la programmation procédurale, et environ 30 ans de moins d'expérience en génie logiciel. Avec l'amélioration de choses telles que les bibliothèques existantes, les langages de haut niveau, les IDES, et la quantité de documentation et d'exemples disponibles sur internet, combien de parties du livre restent-elles vraies ?

Alors que je peux croire que l'ajout de nouvelles personnes à un projet pourrait initialement le ralentir, je pense que des choses telles que les tests unitaires, la séparation des préoccupations, et d'autres formes d'automatisation et d'améliorations de conception permettraient aux nouveaux membres d'une équipe de devenir productifs plus rapidement que ce qui est supposé dans le livre, en supposant que le projet avait une bonne documentation de conception et des processus en place.

Je n'ai pas d'expérience sur les grands projets ou avec de grandes équipes, donc je suis intéressé à entendre ce que ceux d'entre vous qui ont de l'expérience avec eux pensent. édition : Je me demandais si de nouveaux outils de communication tels que les Wikis, les messageries instantanées, et internet en général avaient diminué le temps passé à communiquer. Basé sur les réponses de tout le monde, je dirais que toute augmentation de l'efficacité de la communication a été compensée par une complexité accrue.

Answer 1

C'est toujours aussi vrai aujourd'hui qu'au jour où il a été écrit. Cela est dû au fait que ce texte traite fondamentalement de la communication entre les personnes travaillant sur le même projet, et aucune des avancées des 30 dernières années n'a fondamentalement changé cela.

Bien sûr, nous avons beaucoup appris au cours de ces 30 années, mais toutes les améliorations apportées à nos outils et à notre compréhension ont été progressives, conformément à la prédiction de Brooks selon laquelle il n'y a pas de "silver bullet" (solution miracle).

Answer 2

N'est-ce pas un peu comme demander si L'art de la guerre de Sun Tzu est toujours applicable à la guerre alors que nous avons du matériel moderne ?

Answer 3

Le livre a encore des choses à nous dire, et pour ma part j'ai vécu les problèmes de communication que les tailles d'équipes croissantes posent. Vous devriez savoir que les tests unitaires, la séparation des préoccupations etc. ne sont pas des concepts nouveaux.

Cependant, certaines choses n'ont pas résisté à l'épreuve du temps. Je ne crois pas que écrire des organigrammes ASCII dans votre code soit une bonne idée, et l'approche de l'équipe "chirurgicale" suggérée a été essayée par plusieurs personnes (dont Charles Simony chez MS, le plus célèbre) et a été jugée inefficace.

Answer 4

L'idée n'est pas que les "grandes équipes ne fonctionnent pas", c'est que "jeter des gens/de l'argent sur le problème n'est pas la réponse". Des choses comme les tests unitaires, la séparation des préoccupations, etc. font d'autres choses plutôt que de simplement jeter des gens sur le problème. Ces autres choses vous permettent d'ajouter prudemment plus de gens au bon endroit pour accélérer les choses. En fait, les points que vous soulevez soutiennent les idées du livre.

Answer 5

Les deux célèbres écrits de Brooks, "Pas de baguette magique" et "Le Mythe du Mois Homme", sont des explications sur les limitations fondamentales, dans les langages de programmation et la gestion de projet respectivement.

Alors qu'il est vrai que certains des chapitres un peu plus loin que la moitié de TMMM traitent trop de la technologie de l'époque, les chapitres restants sont toujours aussi pertinents aujourd'hui qu'ils l'étaient à l'époque de leur rédaction.

Dans TMMM, Brooks suit une technique de "définir le problème", "montrer quelques faux départs" et "proposer ma propre solution". Certains commentateurs ont souligné que ses propres solutions pourraient être considérées comme dépassées à ce stade, mais sa description concise des problèmes inhérents aux grands projets rend le livre intéressant.

Un thème sur lequel il revient continuellement est la surcharge des communications en tant que facteur limitant pour les grandes équipes. En tant qu'expérience de réflexion, envisagez l'effet de l'Internet en tant que moyen de communication pour les programmeurs, et le catalyseur qu'il a été pour les grands projets open source.

Personnellement, je lirais le livre juste pour la section "Les Joies de l'Artisanat". Je n'ai jamais lu quelque chose qui décrit aussi élégamment ce que la programmation à son meilleur ressemble. (Si vous êtes curieux, c'est à la page 7, et visible dans la fonction "Aperçu" d'amazon.com)