12 干将莫邪
每个编程人员也保留着编辑器、排序、内存信息转储、磁盘实用程序等工具。 这种方法对软件项目来说是愚蠢的。首先，项目的关键问题是沟通，个性化的工具妨碍--而不是促进沟通。
交互式编程
MIT的Multics项目的成果之一，是它对软件编程系统开发的贡献。在那些系统编程所关注的方面，Multics（以及后续系统，IBM的TSS）和其他交互式计算机系统在概念上有很大的不同：多个级别上数据和程序的共享和保护，可延伸的库管理，以及协助终端用户共同开发的设施。我确信在某些应用上，批处理系统决不会被交互式系统所取代。
13 整体部分
许许多多的失败完全源于那些产品未精确定义的地方。
"细致的功能定义、详细的规格说明、规范化的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的bug数量。 注: 需求文档越详细，bug越少
在编写任何代码之前，规格说明必须提交给测试小组，以详细地检查说明的完整性和明确性 注: 需求文档给测试过一遍 他将程序开发划分成体系结构设计、设计实现和物理编码实现，每个步骤可以使用自顶向下的方法很好地实现。
好的自顶向下设计，从几个方面避免了bug。
首先，清晰的结构和表达方式更容易对需求和模块功能进行精确的描述。
其次，模块分割和模块独立性避免了系统级的bug。
另外，细节的隐藏使结构上的缺陷更加容易识别。
最后，设计在每个精化步骤的层次上是可以测试的，所以测试可以尽早开始，并且每个步骤的重点可以放在合适的级别上。
一些糟糕的系统往往就是试图挽救一个基础很差的设计，而对它添加了很多表面装饰般的补丁。自顶向下的方法减少了这样的企图。
14 祸起萧墙
当人们听到某个项目的进度发生了灾难性偏离时，可能会认为项目一定是遭受了一系列重大灾难。然而，通常灾祸来自白蚁的肆虐，而不是龙卷风的侵袭。
里程碑
里程碑的选择只有一个原则，那就是，里程碑必须是具体的、特定的、可度量的事件，能够进行清晰定义。
例如："结构师和实现人员签字认可的规格说明"，"100%源代码编制完成，纸带打孔完成并输入到磁盘库"，"测试通过了所有的测试用例"。
如果里程碑很模糊，老板就常常会得到一份与实际情况不符的报告。 慢性进度偏离是士气杀手。Microsoft的Jim McCarthy说："如果你错过了一个最终期限（deadline），确保制订下一条deadline
如果在某项活动开始之前就着手估计，并且每两周进行一次仔细的修订，根据实际情况动态调整时间。当里程碑
没有正确反映损失的时间，并对人们形成误导，以致事态无法挽回的时候，它会彻底碾碎小组的士气。
保持进度透明可见
一线经理的利益和老板的利益是内在冲突的。一线经理担心如果汇报了问题，老板会采取行动,这些行动会取代经理的作用，降低自己的威信，搞乱了其他计划。所以，只要项目经理认为自己可以独立解决问题，他就不会告诉老板。
有两种掀开毯子把污垢展现在老板面前的方法，它们必须都被采用。
-
一种是减少角色冲突和鼓励状态共享
减少角色的冲突。老板必须规范自己，不对项目经理可以解决的问题做出反应。当项目经理了解到老板收到项目报告之后不会惊慌，或者不会越俎代庖时，他就逐渐会提交真实的评估结果。
-
另一种是猛地拉开地毯。
猛地拉开地毯。不论协作与否，拥有能了解状态真相的评审机制是必要的。PERT图以及频繁的里程碑是这种评审的基础。大型项目中，可能需要每周对某些部分进行评审，大约一个月左右进行整体评审。
没有银弹
软件工程中的根本和次要问题
没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。因为软件有无法规避的特性：复杂度、一致性、可变性、不可见性。
产品复杂度：
由于复杂度，团队成员之间的沟通非常困难，导致了产品瑕疵、成本超支和进度延迟；
由于复杂度，列举和理解所有可能的状态十分困难，影响了产品的可靠性；
由于函数的复杂度，函数调用变得困难，导致程序难以使用；
由于结构性复杂度，程序难以在不产生副作用的情况下用新函数扩充；由于结构性复杂度，造成很多安全机制状态上的不可见性。
复杂度不仅仅导致技术上的困难，还引发了很多管理上的问题。它使全面理解问题变得困难，从而妨碍了概念上的完整性；它使所有离散出口难以寻找和控制；它引起了大量学习和理解上的负担，使开发慢慢演变成了一场灾难。
软件可变性：
软件实体经常会遭受到持续的变更压力
现实工作中，经常发生两种情况。
当人们发现软件很有用时，会在原有应用范围的边界，或者在超越边界的情况下使用软件。功能扩展的压力主要来自那些喜欢基本功能，又对软件提出了很多新用法的用户们。
其次，软件一定是在某种计算机硬件平台上开发，成功软件的生命期通常比当初的计算机硬件平台要长。即使不是更换计算机，则有可能是换新型号的磁盘、显示器或者打印机。软件必须与各种新生事物保持一致。
软件不可见性
软件是不可见的和无法可视化的。 其中的秘密就是逐步发育成长，而不是一次性搭建。
软件开发是一件棘手的事情，并不会有魔术般的解决方案，现在是从业者研究和分析革命性进展的时刻，而不是等待或希望它的出现。
现在有可能可以在软件生产率上取得逐步的进展，而不是等待不可能到来的大突破。
