试验性工厂和增大规模
开发一个更灵巧或者更好的系统。系统的丢试图和重新设计可以一步完成，也可以一块块地实现。
为舍弃而计划，无论如何，你一定要这样做。
唯一不变的就是变化本身
目标上的一些变化无可避免，事先为它们做准备总比假设它们不会出现在好得多。不但目标上的变化不可避免，而面设计策略和技术上的变化也不可避免。
为变更设计系统
细致的模块化、可扩展的函数、精确完整的模块间接口设计和完备的文档。
变更的阶段化是一种必要的技术。每个产品都应该有数字版本号，每个版本都应该有自己的日程表和冻结日期，在此之后的变更属于下一个版本的范畴。
为变更计划组织 架构
当系统发生变化时，管理结构也需要进行调整。
管理人员需要参与技术课程，高级技术人才需要进行管理培训。项目、进展和管理问题必须在高级人员整体中得到共享。
只要能力允许，高层人员必须时刻做好技术和情感上的准备，或者队亲自参与开发工作。其工作量很大，但很值得。
前进两步，后退一步
程序维护中的一个基本问题是：缺陷修复总会以固定（20%~50%)的几率引入新的bug，所以，整个过程是前进两步，后退一步。
作为引入新bug的一个后果，程序每语句的维护需要的系统测试比其它编程要多。理论上，在每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以更隐蔽的方式被破坏。实际情况中，回归测试必须接近上述理想善，所以它的成本非常高。
前进一步，后退一步
Lehman和Belady发现模块总数量随版本号的增加呈线性增长，但是受到模块数量随版本号的增加呈指数增长。所有修改都倾向于破坏系统 的架构，增加了系统的混乱程度（熵）。