人月神话--未雨绸缪

不变只是愿望，变化才是永恒

普遍的做法是，选择一种方法，试试看；如果失败了，没关系，再试试别的。不管怎么样， 重要的是先去尝试

为了舍弃而计划，无论如何，你一定要这样做

开发人员交付的是用户满意 程度，而不仅仅是实际的产品。用户的实际需要和用户感觉会随着程序的构建、测试和使用 而变化

我从不建议顾客目标和需求的所有变更必须、能够、或者应该整合到设计中。项 目开始时建立的基准，肯定会随着开发的进行越来越高，甚至开发不出任何产品

不愿意为设计书写文档的原因，不仅仅是 由于惰性或者时间压力。相反，设计人员通常不愿意提交尝试性的设计决策，再为它们进行 辩解。“通过设计文档化，设计人员将自己暴露在每个人的批评之下，他必须能够为他的每 个结果进行辩护。如果团队架构因此受到任何形式的威胁，则没有任何东西会被文档化，除 非架构是完全受到保护的。

在大型的项目中，项目经理 需要有两个和三个顶级程序员作为技术轻骑兵，当工作繁忙最密集的时候，他们能急驰飞奔， 解决各种问题

当系统发生变化时，管理结构也需要进行调整。这意味着，只要管理人员和技术人才 的天赋允许，老板必须对他们的能力培养给予极大的关注，使管理人员和技术人才具有互换 性

起初，上一个版本中被发现和修复的bug ，在新的版本中仍 会出现。新版本中的新功能会产生新的bug 。解决了这些问题之后，程序会正常运行几个月。 接着，错误率会重新攀升。Campbell 认为这是因为用户的使用到达了新的熟练水平，他们 开始运用新的功能。这种高强度的考验查出了新功能中很多不易察觉的问题

程序维护中的一个基本问题是——缺陷修复总会以（20－50 ）% 的机率引入新的bug 。 所以整个过程是前进两步，后退一步

Lehman和Belad y 研究了大型操作系统的一系列发布版本的历史 6 。他们发现模块数量 随版本号的增加呈线性增长，但是受到影响的模块以版本号指数的级别增长。所有修改都倾 向于破坏系统的架构，增加了系统的混乱程度