有多少神话人物月仍然适用？ [关闭]答案

【问题标题】：How much of the Mythical Man Month still applies? [closed]有多少神话人物月仍然适用？ [关闭]
【发布时间】：2010-10-23 16:05:42
【问题描述】：

这本书是在分时系统、过程式编程和软件工程经验少了大约 30 年的时代写成的。随着现有库、高级语言、IDES 以及 Internet 上可用文档和示例的数量等方面的改进，这本书有多少仍然适用？

虽然我相信向项目中添加新人员最初可能会减慢项目的速度，但我认为诸如单元测试、关注点分离以及其他形式的自动化和设计改进之类的事情将使团队的新成员变得富有成效比书中假设的要快，假设项目有良好的设计文档和流程。

我没有大型项目或大型团队的经验，因此很想听听那些有经验的人的想法。编辑：我想知道新的通信工具，例如 Wiki、即时消息和互联网是否能减少花费在通信上的时间。根据每个人的回答，我会说通信效率的任何提高都被复杂性的增加所抵消。

【问题讨论】：

在我看来，假设好的设计文档和流程是一个相当大的假设。什么是大型项目或团队？如果该项目需要一两年的时间，那么大型项目还是您更愿意让项目需要接近十年的时间才能大型化？
也不要忘记，从那时起，一般的复杂性已经增长了很多......
如果你有周年纪念版，它应该包含一章名为“没有重燃银弹”的章节，布鲁克斯在 25 年后反思他的“没有银弹”声明。
它实际上是关于在分时系统之前的时代——OS/360 是一个批处理操作系统。
其中经常提到分时。

标签： project-management

【解决方案1】：

今天它仍然像它写成的那一天一样真实。这是因为它从根本上是关于从事同一项目的人们之间的交流，而过去 30 年的进步都没有显着改变这一点。

当然，在这 30 年中，我们学到了很多东西，但根据 Brooks 的“没有灵丹妙药”的预测，我们工具和理解的所有改进都是渐进式的。

【讨论】：

我大约 4 年前读过这本书，我怀疑任何关于 40 年前构建的操作系统的文章，更不用说比我父亲年长的人写的关于 IT 的文章，是否与今天相关，我被震撼了远离我每天所做的事情。很少有 IT 书籍可以针对技术而不是语言，而这本书完美地做到了这一点。仍然像以往一样具有相关性！
他谈到的另一部分是没有灵丹妙药来克服这个问题。
我意识到其中大部分是关于沟通的。我想知道像 Wiki 的电子邮件和即时通讯这样的东西是否会减少沟通需求，从而更快、更省时。似乎任何速度的提高都被增加的复杂性所平衡，从而导致更多的通信。
维基、电子邮件和即时消息正在取代其他形式的通信；总的来说，沟通并没有减少。
布鲁克斯确实讨论了一些当时非常先进的通信技术。然而，改进通信技术只能获得有限的改进。这有点像在 O(n!) 算法中进行 O(n) 改进。

【解决方案2】：

这不就像问孙子兵法在我们有现代装备的情况下还适用于战争吗？

【讨论】：

+1 因为任何提及战争艺术的东西都很棒
我只是在写这就像牛顿仍然相关，即使我们有量子力学。
我一直以为飞行终于淘汰了孙子兵法。
我还以为孙子学院被移动战淘汰了……

【解决方案3】：

这本书仍然有一些事情要告诉我们，而且我已经经历过团队规模增加带来的沟通问题。您应该知道，单元测试、关注点分离等并不是新概念。

然而，有些事情并没有经受住时间的考验。我不认为在你的代码中编写 ASCII 流程图是一个好主意，建议的“外科团队”方法已经被几个人尝试过（最著名的是 MS 的查尔斯西蒙尼），发现效果不太好。

【讨论】：

布鲁克斯后来说他最大的错误是建议开发人员尽可能多地了解其他人代码的内部知识，而不是强制执行边界。我仍然认为这本书对于教授如何做软件至关重要。
这本书带有不必要的宗教花絮，有点难以阅读。见amazon.ca/gp/customer-reviews/R2M9G9ZKMFCWI9/…
您对 simonyi 的手术方法试验有参考吗？

【解决方案4】：

这个想法不是“大团队不起作用”，而是“把人/钱扔在问题上不是答案”。诸如单元测试、关注点分离等之类的事情正在做其他事情，而不仅仅是让人们解决问题。这些其他的东西可以让你小心在正确的地方添加更多的人来加快速度。如果有的话，你提出的观点支持了本书的想法。

【讨论】：

Brooks 谈到了对大型团队的需求，指出像小型团队这样的团队无法在任何合理的时间内完成 OS/360。

【解决方案5】：

著名的布鲁克斯著作《没有银弹》和《神话般的人月》分别解释了编程语言和项目管理方面的基本限制。

虽然有些章节在 TMMM 中略过一半，但过多地涉及当时的技术，但其余章节在今天仍然与编写时一样重要。

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

他反复提到的一个主题是通信开销是大型团队的一个限制因素。作为一个思想实验，考虑一下互联网作为程序员交流媒介的影响，以及大型开源项目的催化剂。

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

【讨论】：

【解决方案6】：

我当然认为“没有灵丹妙药”之类的东西在今天和几十年前一样适用，尤其是当我们看到越来越多的年轻人进入行业并认为 x 是最新和最伟大的杀手语言/技术以及所有其他技术将因此而消亡。

诚然，对 Ada 或共享计算机的引用已经过时，但偶然和基本困难的概念、购买与构建、代码在定义上是多么复杂，因为我们不重复部分，以及所有其他理论主题都是仍然完全准确和相关。

关于 TMMM 为何如此重要的另一个论据是，它实际上与软件本身无关，而与程序员如何完成工作有关。这样就很难过时了。

【讨论】：

【解决方案7】：

让我印象深刻的两个：“第 2 版”仍然适用，“添加更多人不一定更快”也是如此。

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

与 MMM 被识别时相比，沟通变得更有效率，但是，我认为这一切都是成比例的。与编写 MMM 时相比，准备软件生产所需的时间要多得多。

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

【讨论】：

【解决方案8】：

将 TMM 作为一本书来概述软件工程中的一个问题，也许是 THE 问题：它不是技术，而是人！您提到的所有改进都源于该核心实现。他们都准备好解决布鲁克斯提出的问题。我相信肯特·贝克、沃德·坎宁安、阿利斯特·科克本和马丁·福勒都读过这本书，深信不疑，然后开始制作他们的灵丹妙药。

【讨论】：

【解决方案9】：

我认为这是任何想要了解软件开发过程的人的“必读”书籍之一。

【讨论】：

【解决方案10】：

过去 40 年来，对开发劳动力的需求一直在快速增长，而且这种需求不会停止。由于人口中聪明人（参见 Joel 的“聪明并把事情做好”）的比例基本保持不变，每年教育越来越多的开发人员意味着开发人员的平均聪明程度越来越低。
40 年前，半神成为开发者； 20 年前，这是一份适合聪明人的工作，而现在当我在我的母校看到年轻的 CS 学生时，似乎他们正在接受所有知道计算机是什么的人。
这并不意味着灾难即将来临——西方世界不断从新兴市场或第三世界国家引进聪明人（或外包工作）。新的开发工具使开发良好的应用程序变得更加容易。这些因素似乎相互抵消，使 MM-M 永恒真实。

【讨论】：

【解决方案11】：

神话人物月是一本非常过时的读物，但核心真理仍然适用。 Sure Brooks 讨论了对秘书的需求，这在今天显然是不正确的，他的外科团队概念并不适用，但本书的大部分内容仍然是准确的。他认为沟通需求随着团队规模的增加而增加的观点仍然正确。他观察到，将人员添加到后期项目中会使它变得更晚，这已被许多项目所证实。单元测试有一点帮助，但它们并不能阻止人们误解代码或提出很多问题。没有银弹也能继续经受住时间的考验。

【讨论】：

令我惊讶的是，许多重要的东西仍然没有过时。

【解决方案12】：

全部。一个简单的事实是软件项目是不平凡的。我们将自己的领域知识直接构建到我们的解决方案中。领域知识转移对转让方和受让方来说都是昂贵的；这没有改变。我，一方面，相信它永远不会，无论使用什么实践和工具。事情可能会稍微好一些，但简单的事实是，教与学都是昂贵且困难的事情，没有办法避免它们。

【讨论】：

【解决方案13】：

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

技术示例几乎完全过时，只有当您考虑 1964 年的 0.034 MIPS System/360 时才有意义。当您只有 8 KB 内存时，建议用户应该负责处理闰年，而不是浪费 26 字节的系统内存（就像 Brooks 所做的那样）是有道理的，但今天它似乎非常愚蠢。我不知道今天有这么小的系统——你的电话比最强大的 OS/360 系统强大数千倍。今天我们对可用性和人机交互有了更多的了解，让用户对这类事情负责简直是疯了。

【讨论】：

【解决方案14】：

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

如果/当我开始一个具有良好设计文档和流程的项目时，我会告诉你这是否有任何改进。

【讨论】：

当你开始那个项目时给我打电话！

【解决方案15】：

如果您想到一个迟到的大型项目，那么它很可能处于危机/恐慌模式，就像在这种模式下的大多数事情一样，最好的答案是一个半体面的计划，简单地在危机中投入更多资源并不除了浪费资源和复杂化问题之外，别无他法。

调度（发音为shed-uling）、计划和体面的管理是无可替代的。

与大多数这些“一条线”或“黄金法则”一样，将它们视为更多指导（有上下文）而不是一成不变的。

【讨论】：