办公室政治不是人品问题。它们是任何个人贡献不可见的环境中的结构性必然。当没人知道谁是好贡献者、谁是差贡献者时，存在巨大的社交操纵激励。 熵增偏好栈，舒服优于简单、复杂优于困难、追责优于学习，就是这种迷雾选择出来的。最终这些操纵消耗的情感能量超过实际工作，后者的质量下降。
简单的画面
在村子里，人人知道谁烤的面包最好。面包师的声誉是可见的、分布式的、靠直接经验挣来的。在公司里，没人知道谁写的代码最好，因为所有代码都埋在只有三个人看得懂的单体里。于是”谁是好的”变成了政治问题，不靠产出回答而靠叙事回答。
两种开发模式
小程序开发
工程师写程序。复数。好几个。一个人可能一年贡献二十个项目，每个产出普遍有用的工具。跨层级协作是命脉，人们频繁帮助其他团队，在组织中建立跨部门关系。
一个工程师可以靠是否写出对其他人有用的高质量软件来评判。这种知识在组织中是冗余分布的因为工程师在持续为广泛的人群产出可见的价值。政治环境保持轻量因为一个人的影响力是可见贡献的产物。
小程序开发自然遵循工程算法：小块可以被质疑、删除、简化。即使一个项目失败了，有用的工具被打捞出来。从更小块组合代码的过程意味着有用的部分在项目失败中幸存。 大的专门化块则任凭大项目摆布。
大程序开发
工程师在一个项目上工作。一个大写P的项目，有酷炫的代号、有人头、有时间线。六个月可以花在熟悉一个庞大系统的复杂性上。考虑到两到三年的平均任期，这是不可忍受的。
大项目倾向于变成一种垃圾般的、临时拼凑的领域特定语言。技术债务在这里积累最快：每一个不经重组就添加的功能都埋葬了原有的理解，直到代码库完全不包含理解。要理解其中任何一部分需要理解全部。在任的开发者成为他们领地的独裁者，没人能声称有更好的想法因为没人能理解这个项目。正如丘吉尔可能会说的：这个代码库，凭其体量，保护了自己免于被阅读的风险。
大项目只在完成时交付价值，不是持续交付。如果一半团队辞职，如果项目因任何原因失败，一切都丢了。这是流动原则的反面，不是限制在制品并持续交付，大项目积累最大量的在制品然后到最后什么都不交付。
为什么经理喜欢大项目
经理喜欢大项目有三个原因，全部以牺牲工程效率为代价服务管理利益：
1. 给厉害老板的厉害名字。 经理可以在简历上写”领导了Magneto项目，10万行代码，12人团队”。没人写”促成了47个小工具的生态系统，总共提升了开发者速度30%”。
2. 可追踪性。 Mark在灰姑娘项目上（3人）。Sally在西哥特项目上（5人）。组织图是可读的。可读性服务阅读者，而阅读者永远是管理层。在小程序开发中，人们分散在多个努力中，方式不可计量，而不可衡量的工作对管理思维来说是可疑的工作。
3. 控制。 经理无法控制小程序开发有机的、按需的增长。指挥大项目很直接：做成面向对象的，用这个工具集，周五前完成34个工单中的20个。敏捷批判也落在这里：Scrum的用户故事把工作原子化为可管理的单元不是为了工程利益而是为了管理可读性。
但可追踪性杀死了跨层级协作，让好公司好的那个东西。跨层级的、不被计量的工作使解雇变难，因为一个贡献多个项目的程序员有太多支持者。《人件》直接命名了这一点：全公司范围的精英制度自然倾向于民主考量，这削弱了管理层的权力。经理偏好大项目模式不是尽管它低效而是因为它低效，低效创造了管理层需要的依赖性和可读性。
迷雾
收益在这里。如果John在Lorax项目上每天产出5行代码，那是因为John无能，因为团队没让他融入，还是因为Lorax是一个结构糟糕的项目？
在小程序环境中，这个问题自行回答，John在多个项目中的可见贡献揭示了他的实际能力。在大项目环境中，这个问题无法回答。技术负责人来做评估。自然地，他会选择对自己有利的理论。他永远不会承认Lorax设计得糟或一开始就是个错误。于是John被扔到车底下了。
正是这种战争迷雾创造了办公室政治。 格维斯原则描述了接下来发生的事：社会病态者靠权力话语驾驭迷雾，无知者靠对大项目抽象的忠诚驾驭，失败者靠茶水间的团结驾驭。专家型初学者在这种环境中蓬勃发展因为他们的领域专长不可证伪，没有其他人足够理解项目来挑战他们。古德哈特定律完成了陷阱：无论选择什么指标来评估迷雾中的贡献（代码行数、关闭的工单、速度）都变成了一个偏离实际价值的目标。
语言类比
编程语言只是工具，但社区文化围绕它们形成。Java是为嵌入式系统设计的，比如咖啡壶和机顶盒。它的设计不带有对程序员的意识形态不信任。那种不信任后来才有，当1990年代把编程人才商品化的企图征用了这门语言。
那次企图失败了因为编程本质上是思考，没有任何强制手段能强迫一个人思考。不是强制框架，不是强制测试覆盖率百分比，不是管理工具。如果一个测试套件阻止所有bug进入生产，在人们不个人关心质量的情况下它会阻止所有代码。《人件》原则：方法论是试图集中化思考，而集中化思考是矛盾修辞。
常见误读
低水平理解：“办公室政治是因为有毒的人，招更好的人。”
中等水平理解：“我们需要更好的流程来使贡献可见，实施OKR、代码指标、同行评审。”
更好的理解：战争迷雾是结构性的不是人际的，修复是架构层面的。 小程序开发消解政治不是通过改善人而是通过冗余的、跨团队的证据使贡献可见。滋生政治的迷雾是由项目架构创造的，不是由人性。改变架构，更小的项目、跨团队协作、持续交付有用工具，政治激励就自动改变。再多的文化干预也修不了结构性问题。
核心收获
最深的洞察是管理层的可辨识性和工程精英制度直接冲突。大项目让人头可追踪、项目状态可汇报、个体工程师可控制，全是管理层想要的。小程序开发让贡献可见、协作有机、工程师自主，全是工程需要的。为管理可辨识性优化的公司会像工厂产出废物一样必然地产出办公室政治。为工程可见性优化的公司会产出精英制度，并在过程中吓坏它的经理们。
参考：
- Michael O. Church，Java Shop Politics