神圣人月有多少仍适用？

Question

这本书是在分时系统，程序编程和大约30年的软件工程经验时代编写的。随着现有图书馆，更高级别语言，IDES以及互联网上可用的文档和示例数量的改进，本书的大部分内容仍然适用吗？

虽然我可以相信在项目中添加新人可能最初会减慢速度，但我认为单元测试，关注点分离以及其他形式的自动化和设计改进等事情会让团队中的新成员变得高效假设项目具有良好的设计文档和流程，那么在本书中假设的速度要快得多。

我没有大型项目或大型团队的经验，所以我很想知道那些与他们有过相关经历的人的想法。 编辑： 我想知道像Wikis，即时消息和互联网这样的新通信工具是否会减少通信时间。基于每个人的答案，我会说通信效率的任何提高都被复杂性的增加所抵消。

Answer 1

今天仍然像它写的那一天一样真实。这是因为它基本上是关于在同一个项目上工作的人之间的沟通，而过去30年的进步都没有大幅改变。

当然，我们在这30年中学到了很多东西，但是根据布鲁克斯的“无银弹”预测，我们的工具和工作的所有改进都是渐进式的。

Answer 2

这不就是问孙子的战争艺术是否仍适用于战争，因为我们拥有现代化的设备？

Answer 3

这本书还有一些东西可以告诉我们，而且对于一个人来说，我遇到了团队规模增加带来的沟通问题。您应该知道，单元测试，关注点分离等不是新概念。

然而，有些事情经得起时间的考验。我不相信在您的代码中编写ASCII流程图是一个好主意，并且建议的“手术团队”方法已经被几个人（MS的Charles Simony，最着名的人）尝试过，并且发现不能很好地工作。 / p>

Answer 4

这个想法不是“大型团队不工作”，而是“将问题投入人员/金钱不是答案”。像单元测试，关注点分离等事情正在做其他事情，而不仅仅是让人们解决问题。这些其他内容允许您小心在正确的位置添加更多人 以加快速度。如果有的话，你提出的观点支持这本书的想法。

Answer 5

两个着名的布鲁克斯着作，“无银子弹”和“神话人月”分别是编程语言和项目管理的基本限制的解释。

虽然有些章节比TMMM中途稍微超过了当时的技术，但其余的章节在今天仍然和写作时一样重要。

在TMMM中，布鲁克斯遵循“概述问题”，“展示一些错误的开始”和“提出我自己的解决方案”的技巧。上面的一些评论家指出，他自己的解决方案在这一点上可能被认为是过时的，但他对大型项目中固有问题的简明描述使这本书值得一读。

他不断回归的一个主题是通信开销是大型团队的限制因素。作为思想实验，考虑互联网作为程序员的通信媒介的影响，以及对大型开源项目的催化剂。

就个人而言，我会为“工艺的欢乐”部分阅读这本书。我从来没有读过任何能够如此优雅地描述最佳感觉之类的编程的东西。 （如果你很好奇，那就是第7页，可以在amazon.com上看到“Look Inside！”功能）

Answer 6

我当然认为像“没有银弹”这样的东西今天和几十年前一样适用，特别是当我们看到越来越多的年轻人进入工业界并认为x是最新最好的杀手级语言/技术时其他技术因此而死亡。

当然，对Ada或共享计算机的引用已过时，但是意外和基本困难的概念，购买与构建，代码如何复杂，因为我们不重复部分，所有其他理论主题是仍然完全准确和相关。

TMMM与之相关的另一个论点是，它不是关于软件本身，而是关于程序员如何完成工作。通过这种方式，它很难变得过时。

Answer 7

在我的脑海中突出的两个：“版本2”仍然适用，“添加更多人不一定更快”。

Spolsky以自己的方式讨论“第2版”。我不记得他是否特意链接到MMM，但它在概念上非常相似。

与确定MMM相比，沟通变得更有效率，但是，我认为这一切都是成比例的。与编写MMM时相比，制作软件生产需要更多的准备工作。

有人说计算机科学中的所有内容都是在1960年被发现的，从那以后一切都是衍生的。

Answer 8

阅读TMM作为一本书，概述了软件工程中的一个问题，也许是问题：它不是技术，而是人！您提到的所有改进都源于核心实现。它们都是为了解决布鲁克斯所提出的问题。这本书，我肯定肯特贝克和沃德坎宁安，阿利斯特科克本和马丁福勒都读过，心中然后开始制作他们的银子弹。

Answer 9

对于想要了解软件开发过程的人，我认为这是“必读”之一。

Answer 10

过去40年来，对发展劳动力的需求一直在快速增长，这种需求不会停止。由于聪明的比率（视频Joel的“智能和完成事情”）人口中的人们大致保持不变，每年教育越来越多的开发人员意味着开发人员的平均智慧越来越低。
40年前，成为开发商的是半神人; 20年前，这对聪明人来说是一份工作，而现在当我看到我的母校的年轻CS学生时，他们似乎正在把每个知道电脑是什么的人带走。
这并不意味着灾难即将来临 - 西方世界不断从新兴市场或第三世界国家进口聪明人（或外包工作）。新的开发工具使开发优秀应用程序变得更加容易。这些因素似乎相互抵消，使MM-M永恒真实。

Answer 11

神话人月是一个非常过时的读物，但核心真理仍然适用。 Sure Brooks讨论了对秘书的需求，这在今天显然不正确，他的外科团队概念效果不佳，但本书的大部分内容仍然准确。他对通信需求随着团队规模的增加而增加的见解仍然是正确的。他观察到将人们添加到一个后期项目中后来很多项目已经诞生了。单元测试有一点帮助，但它们并没有阻止人们误解代码或提出很多问题。没有Silver Bullet也经得起时间的考验。

Answer 12

全部。简单的事实是，软件项目是非常重要的;我们将自己的领域知识直接构建到我们的解决方案中。对于转让人和受让人而言，域知识转移成本高昂;这没有改变。而且，无论使用何种做法和工具，我都相信它永远不会。事情可能会略微好转，但简单的事实是，教学和学习既昂贵又困难，而且没有办法避免它们。

Answer 13

社会因素仍然存在，因为人类仍然是我们50年前的野兽。

技术示例几乎完全过时，只有在考虑1964的0.034 MIPS系统/ 360时才有意义。当你只有8 KB的内存时，建议用户应负责处理闰年而不是浪费26个字节的系统内存（正如布鲁克斯所做的那样）是有道理的，但今天它似乎是彻头彻尾的愚蠢。我不知道今天任何小型系统 - 你的电话比最强大的OS / 360系统强大数千倍。今天我们对可用性和人机交互了解得更多，让用户负责这类事情只是疯了。

Answer 14

现在，一个程序员可以编写更多的代码/构建比一个程序员当时更多的软件，但添加第二个开发人员不会产生两倍的数量。

如果/当我开始使用具有良好设计文档和流程的项目时，我会告诉您是否可以改善任何内容。

Answer 15

如果你想到一个迟到的大型项目，那么它最有可能处于危机/恐慌模式，就像这种模式中的大多数事情一样，最好的答案是一个半体面的计划，只是在危机中投入更多资源解决除废物资源以外的任何问题并解决问题。

没有什么可以替代日程安排（宣布脱落），规划和体面管理。

与大多数这些“单线”或“黄金规则”一样，请考虑更多指导方针（有上下文），而不是一成不变。