苦：人们通常希望项目快结束的时候收敛的快一点，但结果是越到最后，收敛越慢。
第二章 人月神话（人月：一个人干一个月，三个人干四个月就是12个人月）
人月是一个危险的带有欺骗性的神话，人员和时间的关系不一定是人越短，项目完成时间越少。除非是完全可分解任务，人与人之间不用沟通。有时候盲目增加人员只会适得其反。
进度安排中，系统测试阶段往往容易安排错误，不确定性太大。编码阶段最容易估算时间
软件进度安排经验：1/3 计划，1/6编码，1/4构件测试和早期系统测试，1/4系统测试。测试占一半时间，这是实际中经常做不到的。
Brooks法则：向进度落后的项目中增加人手，只会让项目更落后。 应该及时修改进度安排和减少项目任务
大型队伍时，要有系统架构师，要能清晰的划分体系结构设计和实现之间的界限，并专注于体系结构
贵族专制好，由智力精英完成创造性工作，其他人做齿轮（齿轮的描述其实不对，程序的实现也是创造性工作），这样有助于概念完整性。但上面的人不用要求下面的人如何做
在体系结构队伍设计时，实现人员干什么？如果让实现人员参与计划设计阶段，并不会加快速度，并且质量更加低劣。所以大型项目可以分阶段，在说明编写好之后再调入实现人员
功能和理解上的复杂程度的比值才是系统设计的最终标准，而不是丰富的功能。
尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。
结构师如何成功地影响实现： 牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而不能支配
时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法
规格说明作者应该追求的精确程度：在仔细定义规定什么的同时，定义未规定什么。
项目经理最好的朋友就是他每天要面对的对手——独立的产品测试机构/小组
仅仅通过对编码部分的估计，然后应用任务其他部分的相应系数，是无法得到对整个任务的估计的。
工作量是规模的幂函数（不是成正比，规模越大，需要的工作量呈幂函数增加）
对常用的编程语句而言，生产率似乎是固定的。这个固定的生产率包括了编程中需要的注释，并可能存在错误的情况。
培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员最重要的职能。
对于计算机硬件开发项目，关键文档是：目标、手册、进度、预算、价格
对于软件项目：目标、用户手册、内部文档、进度、预算、组织机构图、工作空间分配
在软件开发的过程中，往往第一个系统存在的问题挺多，它可能太慢、太大，而且难以使用，或者三者兼而有之。要将诶绝所有的问题，除了重新开始以外，没有其他的办法。系统的丢弃和重新设计可以一步完成，也可以一块块地实现。这是所有大型系统开发必须完成的步骤。
用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。
软件产品易于掌握的特性和不可见性，导致它的构建人员面临永恒的需求变更。
抛弃原型概念本身就是对事实的接受——随着学习的过程更改设计。
对于一个广泛使用的程序，其维护总成本通常是开发成本的40%或更多。
程序维护中的一个基本问题是——缺陷修复总会以固定（20%~50%）的几率引入新的bug。整个过程是前进两步，后退一步。
系统软件开发是减少混乱度（减少熵）的过程，所以他本身是处于亚稳态的。
软件维护是提高混乱度（增加熵）的过程，即使是最熟练的软件维护工作们也只是放缓了系统退化到非稳态的进程。
调试是系统编程中很慢和较困难的部分，而漫长的调试周转时间是调试的祸根。
重大灾害是比较容易处理的，它往往和重大的压力、彻底的重组、新技术的出现有关，整个项目组通常可以应付自如。 但是一天一天的进度落后是难以识别、不容易防范和难以弥补的。
进度表上的每一件事被称为“里程碑”，它们都有一个一个日期。里程碑的选择只有一个原则，那就是里程碑必须是具体的、特定的、可度量的事件，能够进行清晰定义。
自文档化的程序：将文档整合到源程序，这对正确维护是直接有力的推动，保证编程用户能方便、及时地得到文档资料。
第一是借助那些出于语言的要求而必须存在的语句，来附加尽可能多的“文档”信息。
