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

Le Mythical Man Month est une lecture très datée, mais les vérités fondamentales s'appliquent toujours. Bien sûr, Brooks parle du besoin d'une secrétaire qui n'est clairement plus vrai aujourd'hui et son concept d'une équipe chirurgicale ne fonctionne pas bien, mais la plupart du livre est toujours précis. Son insight que les besoins en communication augmentent avec la taille de l'équipe est toujours vrai. Son observation que ajouter des gens à un projet en retard le fait devenir encore plus en retard a été confirmée par de nombreux projets. Les tests unitaires aident un peu, mais ils n'empêchent pas de mal comprendre le code ou de poser beaucoup de questions. Pas de Balle d'Argent continue également de passer l'épreuve du temps.

Answer 2

Tout cela. Le simple fait est que les projets logiciels ne sont pas trivial; nous intégrons nos propres connaissances de domaine, vraiment, directement dans nos solutions. Le transfert de connaissance du domaine est coûteux, tant pour le transfert que pour le destinataire; cela n'a pas changé. Et, pour ma part, je crois que cela ne changera jamais, peu importe les pratiques et les outils utilisés. Les choses peuvent s'améliorer marginalement, mais le simple fait est que l'enseignement et l'apprentissage sont à la fois des choses coûteuses et difficiles, et il n'y a tout simplement aucun moyen de les éviter.

Answer 3

Les facteurs sociaux sont toujours présents, car les humains restent essentiellement les mêmes bêtes que nous étions il y a 50 ans.

Les exemples techniques sont presque totalement obsolètes, et n'ont de sens que si l'on pense au système 0,034 MIPS System/360 de 1964. Lorsque vous n'avez que 8 Ko de mémoire, suggérer que l'utilisateur devrait être responsable de gérer les années bissextiles, au lieu de gaspiller 26 octets de mémoire système (comme l'a fait Brooks) avait du sens, mais aujourd'hui cela semble carrément ridicule. Je ne connais aucun système aussi petit aujourd'hui -- votre téléphone est des milliers de fois plus puissant que le système OS/360 le plus puissant. Aujourd'hui, nous en savons beaucoup plus sur la convivialité et l'interaction homme-machine, et rendre l'utilisateur responsable de cette catégorie de choses est tout simplement insensé.

Answer 4

Un programmeur peut maintenant écrire plus de code/construire plus de logiciels qu'un programmeur ne le pouvait autrefois, mais ajouter un deuxième développeur ne va pas produire deux fois plus.

Si/when je participe à un projet avec une bonne documentation de conception et des processus en place, je vous ferai savoir si cela améliore quelque chose.

Answer 5

Si vous pensez à un grand projet en retard, il est alors très probablement en mode crise/panique, comme avec la plupart des choses dans ce mode, la meilleure réponse est un plan à moitié décent, simplement jeter plus de ressources sur une crise ne résout rien d'autre que gaspiller des ressources et aggraver le problème.

Il n'y a pas de substitut à la planification et à une gestion correcte.

Comme avec la plupart de ces "maximes" ou "règles d'or", considérez-les plutôt comme des directives (avec contexte) que comme des règles immuables.