Back to Details

principle-attack-the-premise

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Attack the Premise

质疑前提

When two or more fixes that share one premise have failed the same gate, suspect the premise, not the fixes.
Why: Each failed fix is evidence against the belief it assumed. A third fix on the same premise spends effort where the evidence already says the cause is not.
Pattern:
  • Write the premise down. The premise is the one sentence that every failed fix assumed.
  • Test the premise before the next fix. Find an observation that would come out differently if the premise were false, and make it. Look at how the failures are distributed, not only at how large they are. Make the check rerunnable per Build the Lever.
  • Follow the evidence. If it contradicts the premise, the cause is elsewhere. Look for what the failures have in common that the premise did not predict. If it confirms the premise, ask the next "why" per Fix Root Causes. The earlier fixes may have treated a consequence instead of the cause.
  • Remove the condition instead of compensating for it, per the Laziness Protocol. If the evidence shows that one part always lands on the losing side, change what puts it there. A mechanism that cleans up after it leaves the cause in place and adds work on every run.
Stop: Do not start the next fix before the premise is written down and tested.
This principle is distinct from Redesign from First Principles, which rebuilds a design around a new requirement. It questions a fact the current design assumes.
当两个或更多共享同一前提的修复都未通过同一道检查时，应怀疑前提，而不是各个修复。
原因： 每次失败的修复，都是对它所依赖信念的反驳。如果第三次修复仍基于同一前提，就会在证据已经表明原因不在那里的情况下继续消耗精力。
模式：
  • 将前提写下来。 前提是每个失败修复都曾假定的那一句话。
  • 在下一次修复之前测试前提。 找一个如果前提为假就会产生不同结果的观察，并实际执行它。关注失败是如何分布的，而不只是失败的程度。按照 Build the Lever 的要求，让这项检查具备可重复执行性。
  • 遵循证据。 如果证据与前提矛盾，说明原因在别处。寻找这些失败中共同存在、但前提未能预测的因素。如果证据证实了前提，则按照 Fix Root Causes 的方法继续追问“为什么”。之前的修复可能只是处理了结果，而没有处理原因。
  • 移除产生问题的条件，而不是为其进行补偿，具体参见 Laziness Protocol。如果证据表明某个部分总是落在失败的一侧，就改变导致它落在那里的机制。事后进行清理的机制只会让原因继续存在，并且每次运行时都会增加额外工作。
停止条件： 在将前提写下来并完成测试之前，不要开始下一次修复。
这一原则不同于 Redesign from First Principles。后者围绕新的需求重新构建设计，而这一原则用于质疑当前设计所假定的事实。