编程系统产品（Programming Systems Product）开发的工作量是供个人使用的、独立开发的构件程序的九倍。这句话让我有点惊讶，感觉编程好像还是有点含金量的。
之后就第二章里，缺乏合理的时间进度是造成项目滞后的最主要原因。这个深有体会，现在我们团队的项目进度很慢就有这个原因，导致这种现象的原因书中有大约五条，
第一，我们对估算技术缺乏有效的研究，我们总是基于一种不真实的假设——一切都将运作良好。
第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。
第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。
第四，对进度缺少跟踪和监督。其他工程领域中，经过验证的跟踪技术和常规监督程序，在软件工程中常常被认为是无谓的举动。
第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。
我们团队除了第五项，基本都犯了。
然后就是个人对一些章节的总结（觉得说的很有道理的）
所有的编程人员都是乐观主义者：“一切都将运作良好”。所以系统编程的进度安排背后的第一个假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。
计算机编程基于十分容易掌握的介质，编程人员通过非常纯粹的思维活动——概念以及灵活的表现形式来开发程序。正由于介质的易于驾驭，我们期待在实现过程中不会碰到困难，因此造成了乐观主义的弥漫。而我们的构思是有缺陷的，因此总会有bug。
我们围绕成本核算的估计技术，混淆了工作量和项目进展。用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。
关于进度安排，我的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。
Brook法则：向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later）向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通。