干将莫邪：软件的开发离不开工具，从需求的分析，到系统的设计，到程序的编码，到构建、测试、发布和维护，我们要善于利用工具来提高我们工作的效率和质量。
整体部分：面向对象编程的“封装”思想和结构化编程的“精化”思想对于整个软件开发过程的各个粒度同样适用。整体的顺利运行离不开各个组成部分的优化。编码时各个信息隐藏的模块需要完成各自的任务，再通过接口互相配合。测试时需要从最小的单元测试开始，每一粒度都测试完全时，整个系统的运行才有保证。当系统出现问题，需要找到问题的发生点，这时就需要将问题在不同的模块和粒度上分解测试，最终找到问题的症结。
没有银弹：软件活动的根本任务是打造构成抽象软件实体的复杂概念结构。在软件实现的过程我们常常会遇到一个看起来简单的东西却严重影响了软件的质量和进度。人们希望找到一种方法能完美解决这个问题。然而，经过多年的探索，我们发现，这样的方法根本不存在，于是催生了软件工程这个学科来针对软件过程中的每个细分进行方法论的指导。在解决这个问题的过程中，人们也做了很多努力，提出了高级编程语言、面向对象编程、人工智能、专家系统、图形化系统、程序验证、工作站等方式，这些对于软件工程的发展都产生了重要的影响。
20年后的人月神话：如果要我用一个词语来概括人月神话，我想我会说“沟通代价”；如果可以有两个词，那就加上“概念完整性”。
20年后的人月神话有些结论得到验证，有些情况已经变化，下面是这些情况的简单概括：
- 第二系统定律得到验证：开发第二个系统总是因为盲目的功能导致易用性、甚至是可用性的灾难。
- 图形界面的成功
- 瀑布模型被证明是错的了，因为没有构建舍弃原型。事实上增量开发与快速迭代才是理想的开发方式。
- 增量开发和快速原型，渐进地精华，让软件像生物进化那样逐渐演化成更为复杂的结构，演化出更多的功能。
- 信息隐藏：Parnas是正确的，我是错误的。20年前关于信息隐藏的两大观念，其一是Brooks主张的，所有的程序员应该了解所有的材料。而Parnas则认为代码模块应该采用定义良好的接口来封装，这些模块内部结构应该是程序员的私有财产。Brooks承认，Parnas所主张的方案确实更符合实际。
- 对人月神话实际研究发现，向进度落后的项目中添加人手会增加项目的成本，但是不一定会使项目更加落后。如果在项目早期添加额外的人比在后期添加额外的人更安全些。
- 人就是一切。这一点可以从《人件：高生产率的项目和团队》可以见出。
- 放弃权利的力量——公司通过将权利下放到具体的团队，事实上使得组织机构变得更加“融洽和繁荣”。
- 最令人惊讶的新事物——数百万的计算机
- 使用塑料包装的成品软件包作为构建：成熟的模块和对象组合提升了软件复用的层次。
人月是一个神话，现如今软件工程却是真实地在解决软件过程中的问题，提高软件产品的质量。研究人员和实践人员的不断探索或许永远无法一劳永逸地解决所有问题，但是从中积累地经验却能够有效地指导我们更好地应对大型软件系统的实现与管理。