为了得到整体的可运行和高质量的软件，我们需要在哪些方面进行改进和下功夫。这章主要从消除Bug的设计，构件单元测试和系统集成调试三个方面来谈。
消除Bug的设计，就让我们更加意识到质量是设计出来的，而不是测试出来的。V.A.Vyssotsky 提出许许多多的失败完全源于那些产品未精确定义的地方。这要求我们在需求和设计阶段要保持高质量，减少缺陷泄漏。对于需求要有详细的需求规格说明书，对于设计我们提倡的是从顶向下逐步求精的设计，而这里面最重要的就是结构化的设计方法和思路，不论是面向结构和面向对象其实都要遵守结构化的设计方法。
在构件单元测试中讲的很多内容暂时无法和我们现在实际软件开发所对应，但是现在的敏捷开发方法论仍然强调测试驱动，先编写单元测试用例再开发代码，足见单元测试在敏捷软件开发中的重要地位，它不仅仅起到了测试的作用，更重要的是通过测试用例的编写喜欢需求和完善设计思路。
对于大型软件系统，产品集成和集成测试具有重要的地位，为了系统的有计划的降低系统集成调试的困难性我们需要采取多种方法和措施。其中包括了首先对于单个构建必须经过充分的单元测试，否则单元测试的问题将遗留到集成测试阶段导致问题复杂化；其次是搭建充分的测试平台，测试平台往往需要编写测试代码，特别是还可能开发各种伪构件来验证数据集成的正确性。最后是在集成期间要严格控制变更，最好是阶段化的定期变更。
使项目进度拖后的最大原因不是重要的事件，如新技术、重组等，而是一些琐碎的小事，每件小事只耽误半天或一天时间，但这种小事多以后，将使项目的进度严重拖后。慢性的进度偏离是士气杀手，这里核心思想就是要意识到进度滞后往往如温水煮青蛙一样让我们难以应付，最重要的就是要防微杜渐。重大灾害是比较容易处理的，它往往和重大的压力、彻底的重组、新技术的出现有关，整个项目组通常可以应付自如。 但是一天一天的进度落后是难以识别、不容易防范和难以弥补的。
不同用户需要不同级别的文档。某些用户仅仅偶尔使用程序，有些用户必须依赖程序，还有一些用户必须根据环境和目的的变动对程序进行修改。流程图是被吹捧得最过分的一种程序文档。事实上，很多程序甚至不需要流程图，很少有程序需要一页纸以上的流程图。现实中，流程图被鼓吹的程度远大于它们的实际作用。
某些情况下，因为是开发最新的软件，所以它必须遵循各种接口。另一些情况下，软件的开发目标就是兼容性。在上述的所有情况中，很多复杂性来自保持与其他接口的一致，对软件的任何再设计，都无法简化这些复杂特性。系统中的软件包含了很多功能，而功能是最容易感受变更压力的部分。所有成功的软件都会发生变更。现实工作中，经常发生两种情况。当人们发现软件很有用时，会在原有应用范围的边界，或者在超越边界的情况下使用软件。功能扩展的压力主要来自那些喜欢基本功能，又对软件提出了很多新用法的用户们。简言之，软件产品扎根于文化的母体中，如各种应用、用户、自然及社会规律、计算机硬件等等。后者持续不断地变化着，这些变化无情地强迫着软件随之变化。(软件开发的过程必须要考虑如何适应变化，在需求，设计和编码过程中都需要考虑如何快速响应变化，如何提高软件产品的可扩展性。我们在软件开发生命周期模型上强调增量迭代的思路，强调测试驱动的思路其根本目的就是为了快速响应变化，降低变化带来的风险。
除去软件结构上的限制和简化方面的进展，软件仍然保持着无法可视化的固有特性，从而剥夺了一些具有强大功能的概念工具的构造思路。这种缺憾不仅限制了个人的设计过程，也严重地阻碍了相互之间的交流。(我们推荐快速原型法仍然是为了进来去解决软件不可见性的问题。
作者认为软件开发困难的部分是概念的结构，如规格化、设计和测试等概念的结构，而不是概念的表述和实现概念，虽然实现概念可能占用了小于90%的时间，就如现今的软件开发一样，系统分析通常占用的整个项目开发时间不超过20%，而80%的时间花在编程上一样。
个人感受：
这本书大部分内容都是涉及到团队，人和沟通。对于大型软件工程项目，强调人的重要性。在开篇讲开发人员的职业乐趣，后面又通过巴比塔的沟通重要性，在外科手术队伍中的组件和分工。这些都是涉及到团队中人和交互，只有一个有了积极心态和热情的沟通团队，才可能成就一个伟大的团队。从最后的没有银弹，再次肯定开发工作是一种高智力的脑力工作。在如今的软件发展中，很多人提出一个问题，说到软件发展太慢，跟不上硬件的发展，其实反常的并不是软件发展得太慢，而是计算机硬件技术以一种与人类历史不相配的方式爆发出来。《人月神话》的结论，即人力（人）和时间（月）之间的平衡远不是线性关系，使用人月来作为生产率的一个衡量标准，实际上也就是一个神话。