牙慧集

维基上有人总结了一些定理，多以洋人姓氏命名，适合广大装逼爱好者收藏以备不时之需。姑且听之，遇到有共鸣的就记下来。虽说多是些牢骚话，听听别人的牢骚也比独自一人郁闷健康些。

---

Conway 法则 - （计算机）系统的设计构架取决于开发团队的组织构架

他举例：三个小组合作开发一个产品，最终这个产品必然包含三个以上明显分割的模块，模块间的耦合度取决于各开发组之间的交流程度；

又举例：某人开发一段较复杂的代码，日后另一人追加新功能。后者一般不会直接改动前人的代码，而是倾向封装、继承、扩展，于是最终的产品可以明显看出这个人和那个人的痕迹。

一年多前，我在帮老板重新整理分类已完成的工作内容时认识到这个的（那时我还没读过这个定理）。我起初倾向严格按功能模块分，结果各组都不干，理由是权责要明确，一个东西必须有且只有一人负责，我认同。可组织架构常常会变化 —— 有人离职，有人加入，有的组合并，有的组拆分，有专家从这个组调到那个组仍要兼顾前组的工作但结果记入后组的绩效评估... 所以模块间的关系也就跟着改来改去，时刻反应组织的变迁。

一年后我参与开发的这个产品有十多年的历史，该产品的代码几乎用到了所有可以想见的设计模式，从外部进行一个最简单的数据库读写需要二十个以上的函数层层引用。起初我以阴谋论猜度，认为这是劳方糊弄资方的一种方式，自己给自己找活干，有活干就有饭吃，有更多的活儿干就能招更多人，自己也可以管更多人。看过这条定理以后，我不得不承认自己的浅薄。人人都有自己的想法，最终的结果是诸多想法的合力，也就是说，这个结果很难被阴谋家设计出来。十多年，经历成百上千人之手，产品反映的是组织的变迁。不同国家语言文化的几伙人一起合作，模块划分得越清楚，沟通成本越低执行效率越高。

说到底人员的管理决定了产品的设计，鸡的屁股决定了蛋的大小。

---

Coefficient of Inefficiency/低效系数定理 - 会议的人数和效率呈反比。

皇帝要分宰相的权，就设三公九卿三省六部大学士军机处，想办法把内阁搞大。上周几千人乌泱乌泱聚在帝都开会，每人轮不上说三句话，不出意外果然没通过什么建设性的方案。这定理还有个说法：会议的重要程度和人数呈反比。应用到工作中就是，当你被指派干一件特别不想干的事儿，形式上最积极结果上最消极的应对就是，找来所有相关方开会。

---

Segal 定理 - 带一块表的人知道时间，带两块表的人不确定。

那么带三块表的人呢？

---

Murphy 定理 - 可能发生的坏事必然发生。

程序员知道即便错误率万分之一的程序也绝不能用在银行系统上。否则几万单交易里一单出错都够让银行关门。虽说这个定理反过来说也一样，可能发生的好事必然发生。但人对痛苦的刺激反应比快乐强烈。银行也绝对不会因为那一万次里九千九百九十九次算对了而感到沾沾自喜。不光程序员，其它从事工程专业人，一旦进入细节处理，就成了只看到半瓶水空了的悲观主义者，而且他们肯定早已听说过这个定理。如果你不认同这条定理，凡事都只看到光明的一面，那么恭喜你，你是做大事的人。

---

Gall 定理 - 任何可以运作的复杂系统都是从可以运作的简单系统发展而来的。

中国人说“一屋不扫何以扫天下”，一样的道理。与其幻想一个需要付出极大代价还不知道是否能实现的系统，还不如先做个小样，看看它能不能运作，如果能，再搞搞大。

---

Sowa 之标准定理 - 每当一个主流机构开发了一个系统并宣称它是某某（协议、技术、产品）的官方标准，在随即而来的广泛推广中，一个更简单的系统会成为这个某某（协议、技术、产品）的事实标准。举例：

• PL/I 的推出使得 COBOL 和 FORTRAN 成为商用和科学用编程语言的事实标准
• Algol-68 的推出使得 Pascal 成为学术编程语言的事实标准
• Ada 语言的推出使得 C 成为国防部的事实标准
• OS/2 的推出使得 Windows 成为桌面系统的事实标准

谁有权定标准？政府部门或是像 IBM 这样的业界领袖可以定“官方”标准，但定不了“事实”标准。采用哪个不采用哪个，最终选择权仍在用户手里。关键字“更简单”呼应上面的 Gall 定理，自顶向下的设计除了面临无法实现的风险，还面临无人理睬的风险。

---

Sarnoff 定理 - 传播网络的价值和其受关注程度呈正比。

说实话我到现在也不怎么理解“眼球经济”。为什么网站要流量为王？因为它本质上属于媒体业，流量多了它可以卖广告。可为什么别的行业都要效仿，搞些叫好不叫座吃力赔本赚吆喝的东西，都把自己当媒体了么？

---

Thomas 定理 - 如果人们认为情况属实，那它将会造成真实后果。举例：

• 有谣言说某家银行要倒闭了，人们信了，都去挤兑，结果银行真倒闭了。
• 七十年代石油危机中，有人谣言说厕纸将紧缺，于是大家都开始囤积厕纸，搞得厕纸真紧缺了。
• Keynes 选美定理：人们买股票看的不是其本身价值，而是预期他人对这支股票的判断。

因果有时可以相互作用，经济学就是分析人类行为的逻辑。

---

Goodhart 定理 - 任何社会的或经济的统计数字，一旦成为指导政策的指标，它就失去了信息价值。

这就是为什么天朝老百姓不怎么相信“鸡的屁”（GDP）。这就是为什么两年前我拒绝开发用于本部门的自动 KPI 系统。黄仁宇说用数字管理国家比用理念靠谱，我同意。但数字衡量一个国家、一个公司、一个组织、甚至具体到每个人每件事，真正实现起来困难颇大，计算公式的公平性有争议，为防止作弊公式要时常调整应变。这些困难再加上权力者方面的压力会使得技术手段看起来像是出闹剧。搞统计的普遍被认为是无耻的骗子，很无奈，意志不够坚定脸皮不够厚的趁早别干。

---

Rothbard 定理 - 人们倾向专注于他们不擅长的领域。

真正有天赋的人不学就会，道可道非常道，他们凭的是直觉，别人看来很难的事他们觉得没啥可夸耀的。而那些天资不聪慧的人才勤勤恳恳不断总结经验教训一步一个脚印往前走。整天把股市术语挂着嘴边的人，绝大多数是外行。像我这样写起不老歌来一发不可收的话痨，非但不是职业写手，写得东西也并非自己所长。

---

Godwin 定理 - 随着争论贴的增长，贴中出现用纳粹或希特勒比喻的概率趋向 100%

此定理在表述上有时间和空间的局限性，因为人们的争论未必发生在网络论坛，也未必发生在二战以后的西方社会。任何时候人们激烈的辩论最终都是这么一个结果 —— 失去耐心的参与者给对手扣个大帽子，一棍子打倒。这事放到古代中国，造反发檄文就骂皇帝是桀纣，尽管谁都没见过桀纣；文革时代，两伙人武斗可以相互指责对方是走资派、帝国主义走狗、顽固的封建残余，不需要根据和理由；再到今天的网上论坛，汉奸与爱国贼，粪青和五毛党的标签乱飞，早已忘了讨论的具体问题是什么，人们只关心立场。

人非圣贤，到最后谁都可能失去耐心。所以轻易不要参与注定没有结果的辩论，如做不到就谨记“对事不对人”的原则，如果这也做不到，就享受吵架的乐趣吧。与人斗其乐无穷。

---

Sayre 定理 - 与任何争端的感觉强度成反比的是，其所涉利益的多少。（学院政治是所有政治中最遭的，因为奖金太低

括号中的是 Sayre 教授抱怨的重点，前面那段只是给自己的言论寻找理论依据。就我个人的感觉，在河蟹社会之下，那些大张旗鼓拿出来讨论宣传的东西往往只是鸡毛蒜皮，所谓雷声大雨点小；而真正的利益分肥都在私下里平和地进行，所谓润物细无声。真要把核心利益的东西放在台面上岂不天下大乱？

---

90-90 法则 - 起初的 90% 代码占用了 90% 的开发时间，剩下的 10% 代码占用了另外 90% 的时间。

这种说法表述不清（它意图用 90%+90%=180% > 100% 说明工程耗时远超预算），维基上该词条换了几种说法依旧表述不清。个人经验，软件工程用时很难估算，经常为克服一个的技术难点耽误好几天，有时甚至为了绕过一个克服不了的困难整个方案大改版。数数暴雪的《星际2》跳票了多少次，再看看开复老师爆料的 Vista 开发的坎坷，然后再问问自己有没有看见过每天正常时间上下班的程序员。当我和一个做建筑工程的朋友解释软件与其它项目的区别时，他颇不以为然 —— 其它的工程行业也同样有高风险的难关，凭什么软件是特例呢？

检讨软件这个行业，问题可能是从业员素质不过关 —— 还有哪个行业像我们一样有那么多的“技工”挂着“工程师”的头衔却连时间、成本、风险都估不准呢？还有可能是需求难以控制。人们不会要求一个建筑师造一条地球到月球的通路，因为傻子都知道那样行不通。但人们会向软件工程师提出类似的要求，因为没人证明过这样不行，于是项目就傻乎乎地开工了。写软件和造房子不一样，一切皆有可能。