principle-attack-the-premise

质疑前提

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

原因： 基于同一前提的每次失败，都是关于该前提的证据。

模式：

• 写下前提。 前提就是每个失败的修复措施都基于的那一句话。
• 进行下一次修复前，先做统计。 按参与者统计不均衡情况。统计能显示哪些参与者承担了不均衡，但无法显示不均衡的程度。按照 Build the Lever 的做法，将统计写成可重复运行的脚本。
• 解读偏斜。 如果每次运行中都是相同的少数参与者承担了大部分不均衡，那一定有某种机制让他们担任这一角色。找出分配这一角色的机制。根据 Fix Root Causes，这就是接下来要追问的“为什么”。
• 按照 Laziness Protocol，消除不对称，而不是对其进行补偿。在参与者之间轮换角色、随机分配角色，或转移角色，让每次运行时都没有参与者始终承担这一角色。往返路径、共享池、批量交接或定期重新平衡都会保留原有分配，并在每次运行时增加工作量。

停止：

• 前提尚未写下、统计尚未完成之前，不要开始下一项修复。
• 如果参与者之间的统计结果均衡，则前提不是原因。转而在其他地方寻找原因，并保留统计结果作为证据。

这项原则不同于 Redesign from First Principles：后者围绕新需求重建设计；前者质疑当前设计所假定的一项事实。