这本书是在分时系统、过程式编程和软件工程经验少了约30年的年代编写的。随着现有库、更高级的语言、IDE、以及互联网上可用的文档和示例等事物的改进，这本书还有多少内容仍然适用?
虽然我相信将新成员加入项目可能会最初放慢项目的速度，但我认为像单元测试、关注点分离和其他形式的自动化和设计改进可以让团队的新成员变得比书中假设的更快地变得有生产力，前提是项目具有良好的设计文档和流程。
我没有在大型项目或大型团队中的经验，因此我很想听听那些有这样经验的人的想法。 编辑: 我想知道新的沟通工具(如Wikis、即时消息和互联网)是否减少了沟通时间。根据大家的回答，我认为任何沟通效率的提高都被增加的复杂性所抵消了。
这篇文章写于30年前，但至今依旧真实。因为它根本上讲述了在同一项目上工作的人之间的沟通，而过去30年的进步并没有从根本上改变这一点。
当然，在这30年里我们学到了很多东西，但我们的工具和理解力的所有改进都是渐进式的，符合布鲁克斯所预言的“没有银弹”的原则。
这不是在问孙子兵法是否仍适用于现代战争，因为我们有现代装备吗？
这本书仍然有东西可以告诉我们，我个人经历了团队规模增大带来的沟通问题。你应该知道单元测试、关注点分离等并不是新概念。
然而，有些东西并没有经受住时间的考验。我不认为在代码中编写ASCII流程图是一个好主意，而且建议采用“外科手术团队”方法的人已经尝试过几次（最著名的是微软的Charles Simony），发现效果并不太好。
这个观点并不是认为“大型团队不起作用”，而是“将人/资金投入问题并不是答案”。例如单元测试、关注点分离等，它们并不只是在解决问题时增加人力。这些方法使你可以通过在正确的位置谨慎地添加更多人来加速。事实上，您提出的观点支持该书的理念。
将TMM视为一本书，概述了软件工程中的一个问题，也许是“问题”，即不是技术，而是人！你提到的所有改进都源于这个核心认识。它们都旨在解决布鲁克斯所阐述的问题。我相信肯特·贝克（Kent Beck）、沃德·坎宁安（Ward Cunningham）、阿利斯特·科克伯恩（Alister Cockburn）和马丁·福勒（Martin Fowler）都读过这本书，并深刻领会了其中的精髓，然后开始打造他们的银弹。
我认为这是任何想要理解软件开发过程的人都必须阅读的书籍之一。
