Gall定律

gall定律原文：

“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system. —— John Gall, Systemantics”

这里gall定律是一个经验之谈，包括：

• 通常，一个ok的复杂系统是从一个工作的简单系统逐步演化而来
• 从0设计的复杂系统几乎不行
• 从0设计又不工作的复杂系统，靠打补丁修不好

这个软件开发发展这么多年，大家对于这个“大概率是对的”经验之谈很有认可了；

然后在之前的很多工作中，其实也遇到一些反例，那么到底怎么样，这里就值得聊聊。

另外gall’s law其实谈及两个话题：复杂系统 & 进化

进化这部分刚好触及最近一直在搭建的决策harness系统，值得聊+1；

到底为何？

原因比较直接：

• 过于复杂&规模过大
• 有未知因素

这两个因素导致，复杂的东西没法一开始就规划好，然后一路推过去直接搞定；

这里尤其说下过于复杂的问题，在做项目中，过程中面临的选择往往比最终成品高一个数量级，一个feature往往有多种方案，更不要说像优化这种面临多领域多团队的平衡问题；

也就是上线游戏的能看到的复杂度是x，那么在开始阶段会面临一个10x级别的决策树，那么通过推进项目进度，来进行决策剪枝是一个好的策略；

取舍与关键

这里展开几个点：

• 设计和实现一样都是有成本的，需要平衡来定两者的区别，当实现是比较容易改动的，那么认为实现是设计的一部分也是对的
  • 设计成本的考量就是要和“设计不好的代价”相匹配，一些不可撤回的实现（比如韦伯望远镜），那么就要在设计和验证阶段做巨大投入
• 既然迭代是构建复杂系统的必要&关键环节，那么在迭代基建上给与设计同样的重视度&投入是合理的
  • 迭代和验证在当前AI的RSI阶段中就更关键了

• 信息是整个迭代（或者说控制过程）的关键点，也是比较反直觉的点
  • 做好过程信息收集
  • 复盘阶段沉淀出新的认知和信息
• 更新设计和实现：
  • 设计重构：团队需要持续保持能够描述整体的文档以及技术map，并且保持更新，并且根据这个来review团队整体的设计
  • 实现的（代码这些）重构：这点知易行难，关键在于落地；
    • 技术人员的不靠谱/理想主义，非技术人员的认知/干涉，是落地重构的主要阻力；团队可以围绕这个来开展工作；

任务估量

• 开发中任务估计一直是个难题，
  • 其实复杂和研究性质的任务估时就是不准的（因为可见性不高），开发过程中不必对此纠结。
  • 给与一个经验值+冗余浮动更合理
• 简单事情可以准确估计

一些有意思的case

ai讨论中给出的一些有意思的case：

• 曼哈顿工程用上了人类顶级智能，也符合gall定律：
  • 反应堆出现了意想不到的问题，依靠的是工程师的冗余设计，才没出大事
  • 铀浓缩：三条路线一起走
  • 钚弹：初版原理不同，最后要换方案
• 哈勃->韦伯望远镜
  • 韦伯望远镜是远地望远镜，坏了没法修（哈勃近地还可能修），于是做了巨量的设计验证，最后保证部署运行比较顺利
  • 时间和资金消耗极高