686    但是却不能有效的阻止开发陷入无法预期的恶性循环，最终导致整个系统置身错误之中。

687    将李纳斯定律和哈斯勒定律结合起来，我们不难找到三种软件工程的对应模式：对于开发者不超过三人的小工程，无需领导和预设管理结构。

688    对于中型工程，采用传统的管理模式成本则相对较低。

689    并且可以有效的防止重复劳动，错误追踪，并且能很快的发现详细资料是否有遗漏，从而确保万无一失。

690    在此之上，李纳斯定律和哈斯勒定律共同说明了：对于大型工程，传统管理模式带来的问题和成本增幅，远超过预期的重复劳动的开销。

691    而这种调动大家参与所带来的微小开销并不是一个结构上的缺陷，相反（我们看到）这能比传统方法更有力的保证错误和细节无一遗漏。

692    在大型工程中，应用这两则定律可以让那些传统模式下的本息（沉默成本和边际成本译者按）趋近于零。

693    Linux拆分稳定版和实验版的作法，除了分担风险之外还有一个作用干掉发布期限。

694    实际上，一旦程让序员同时面对刻版的功能列表和该死发布时间，软件的质量就会大打折扣。

695    这是研发中的一个重要问题。

696    感谢来自哈佛商学院的马可·伊恩斯蒂（Marco Iansiti）和艾伦·麦科马克（Alan MacCormack）让我明白了一个道理放松二者任意一个，都可以让工作进程更加有效。

697    一个做法就是制定发布日期，但让功能列表可以变通调整。

698    也就是说，在发布时允许舍弃部分功能。

699    这是稳定版内核开发的基本策略；艾伦·考克斯（Alan Cox，稳定版内核的维护者）定期发布稳定版，但是不承诺何时解决某个问题或者何时添加某个实验版的新功能。

700    另一个做法则是，锁定开发列表但不制定发布时间。