所有的编程人员都有乐观主义，总是相信自己的代码是肯定能运行的。所以在安排项目的进度的时候就会是假设在代码能够在正常运行时因该花费的时间。而现实往往不是乐观，在项目的进展过程中会存在各种不可预知的问题。在这个时候项目经理就会为项目增加人员，然而增加人员反而导致项目进度越来越慢。因为新增加的人员还需要培训，需要时间去了解项目的内容和进展情况。在投入了更多的人力的时候，经理发现项目进度反而更慢他就会投入更多的人力，这种恶行循环导致项目的失败。
根据英文内容这里最好应该翻译为整体和部分。为了得到整体的可运行和高质量的软件，我们需要在哪些方面进行改进和下功夫。这章主要从消除Bug的设计，构件单元测试和系统集成调试三个方面来谈。
之所以谈消除Bug的设计，就让我们更加意识到质量是设计出来的，而不是测试出来的。V.A.Vyssotsky提出许许多多的失败完全源于那些产品未精确定义的地方。这要求我们在需求和设计阶段要保持高质量，减少缺陷泄漏。对于需求要有详细的需求规格说明书，对于设计我们提倡的是从顶向下逐步求精的设计，而这里面最重要的就是结构化的设计方法和思路，不论是面向结构和面向对象其实都要遵守结构化的设计方法。在需求规格说明书完成后要尽快提交给测试小组编写测试用例，测试小组需要Review需求以确认需求完整，无歧义和可测试。
在构件单元测试中讲的很多内容暂时无法和我们现在实际软件开发所对应，但是现在的敏捷开发方法论仍然强调测试驱动，先编写单元测试用例再开发代码，足见单元测试在敏捷软件开发中的重要地位，它不仅仅起到了测试的作用，更重要的是通过测试用例的编写喜欢需求和完善设计思路。
对于大型软件系统，产品集成和集成测试具有重要的地位，为了系统的有计划的降低系统集成调试的困难性我们需要采取多种方法和措施。其中包括了首先对于单个构建必须经过充分的单元测试，否则单元测试的问题将遗留到集成测试阶段导致问题复杂化；其次是搭建充分的测试平台，测试平台往往需要编写测试代码，特别是还可能开发各种伪构件来验证数据集成的正确性。最后是在集成期间要严格控制变更，最好是阶段化的定期变更。
人月神话书如其名一样震撼人心，它引起了许多别的领域的读者对此进行评价。律师，医生，社会学家，心里学家，和软件人员一样对此书提出评论和建议。人们经常通过比较计算机软件开发生产率和硬件制造生产率来支持这个观点，后者在 20 年内至少翻了 1000 倍。
正如第16章所解释的，反常的并不是软件发展得太慢，而是计算机硬件技术以一种与人类历史不相配的方式爆发出来。很多年后作者还是会被道“你现在认为哪些在当时就是错误的？哪些是现在才过时的？哪些是软件工程领域中新近出现的？”很多年来人们对软件生产率和影响它的因素进行了大量的研究，特别是在项目的人员配备和进度之间的平衡。最充分的一项研究是：Barry Boehm 对 63 个项目 的调查，其中大多数是航空项目和 25个 TRW 公司的项目。他的《软件工程经济学》不但包括了很多结果， 而且还有一系列逐步推广的成本模型。 尽管一般商业软件的成本模型和根据政府标准开发的航空软件成本模型中的系数肯定不同， 不过他的模型使用了大量的数据来支撑。我想从现在起，这本书将作为一代经典。他的结果充分地吻合了《人月神话》的结论，即人力（人）和时间（月）之间的平衡远不是线性关系，使用人月作为生产率的衡量标准实际是一个神话。
昨天我又把书翻了一遍，发现大部分内容都是涉及到团队，人和沟通。对于大型软件工程项目 强调人的重要性。在开篇讲开发人员的职业乐趣，后面又通过巴比塔的沟通重要性，在外科手术队伍中的组件和分工。这些都是涉及到团队中人和交互，只有一个有了积极心态和热情的沟通团队，才可能成就一个伟大的团队。从最后的没有银弹，再次肯定开发工作是一种高智力的脑力工作。