1.1 编程系统产品开发的工作量是供个人使用的独立开发的构建的9倍；我估计软件构件产品化引起了3倍的工作量，将软件构件整合成完成系统所需要的设计、集成和测试又强加了3倍的工作量，这些高成本的构件在根本上是相互独立的。
人月神话
2.1 缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素的总和影响还大。
2.2 良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。
2.3 所有编程人员都是 乐观主义者：“一切都将运作良好”。
2.4 由于编程人员通过思维开发，期待在现实中不会遇到困难，但是构思本身有缺陷，因此总会有bug。
2.5 我们围绕成本核算的估计技术，混淆了工作量和项目进度。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。
2.6 在若干人员中分解任务会增加额外的沟通工作量—培训和相互沟通。
2.7 关于进度安排，根据经验是1/3技术啊，1/6编码，1/4构件测试和1/4系统测试。
2.8 我们对自己的估计技术不确定，因此在管理和客户的压力下，常常缺乏坚持的勇气。
2.9 Brooks法则：向进度落后的项目增加人手，只会使进度更加落后。
2.10 向软件项目中增派人手从三个方面增加了项目必要的工作量：任务重新分配本身和所造成的工作中断、培训新人员和额外的相互沟通。
外科手术队伍
3.1 同样有两年经验而且在受到同样培训的情况下，优秀的专业程序员的生产率是较差的程序员的10倍。
3.2 小型、精干的队伍是最好的—思绪尽可能的少。
3.3 两个人的团队，其中一人是领导者，常常是最佳的人员使用方法。
3.4 对于真正意义上的大型系统，小型精干的队伍太慢了。
3.5 实际上，绝大多数大型编程系统的经验显示，一拥而上的开发方法是高成本、速度缓慢、低效率的，开发出的产品无法进行概念上的集成。
3.6 一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法—既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底减少了沟通工作量。
贵族专制、民主政治和系统设计
4.1 概念完整性是系统设计中最重要的考虑因素。
4.2 功能与理解上的复杂程度的比值才是系统设计的最终测试标准，而不仅仅是丰富的功能。
4.3 为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。
4.4 对于非常大型的项目，将体系结构方面的工作与具体实现相互分离是获得概念完整性的强有力方法(同样适用于小型项目)。
4.5 如果要得到系统概念上的完整性，必须要有人控制这些概念—实际上就是贵族专制统治。
4.6 纪律、规则对行业有益。外部的体系结构规定实际上是增强，而不是限制实现小组的创造性
4.7 概念上统一的系统能更快的开发和测试。
4.8 体系结构、设计实现、物理实现的许多工作可以并发进行。
画蛇添足