principle-attack-the-premise

质疑前提

如果两个或更多基于同一前提的修复都未能通过同一道关卡，就该怀疑这个前提，而不是这些修复。

原因： 每次修复失败，都是对其所依赖信念的反证。证据已经表明原因不在这里，却还基于同一前提尝试第三次修复，只会把精力花在错误的地方。

模式：

• 写下前提。 前提就是每个失败的修复都依赖的那句话。
• 在尝试下一个修复前验证前提。 找出一个在前提为假时会得出不同结果的观察，并实际进行观察。关注失败的分布情况，而不只是失败的程度。按照构建杠杆的要求，让检查可以重复运行。
• 遵循证据。 如果证据与前提矛盾，原因就在别处。找出这些失败的共同点，看看前提是否预料到了。如果证据证实了前提，就按照修复根本原因继续追问下一个“为什么”。之前的修复可能处理的是结果，而非原因。
• 按照惰性协议，移除条件，而不是对此进行补偿。如果证据表明某一部分总是落败，就改变导致它落败的因素。事后清理的机制会让原因依然存在，并且每次运行都会增加工作量。

停止： 在写下并验证前提之前，不要开始下一个修复。

这个原则不同于从第一性原理重新设计，后者会围绕新需求重建设计。它质疑的是当前设计所假设的一项事实。