软件为什么能把正常人逼疯

原文来源：Graybeard — 软件本身大多数时候很无聊，但生产软件的过程却能把普通人变成 B 级反派：永远不够快、计划永远要灵活、下一个功能永远是"就是它了"。

作者说他有个小小的"宠物理论"：软件会把人逼疯。

不是霍华德·休斯那种每隔三十分钟洗一次手的不正常，而是另一种——原本判断力正常的成年人，一旦进入软件这个场域，就会慢慢失去对"分寸"的感觉。他见过太多次了，从不同的角度、不同的团队，多到他不觉得这纯粹是某个人的性格问题。

把这些特质拆开看，每一条都不算特别：快、有钱、复杂、抽象，以及几乎无限的"改主意自由"。问题是它们凑在一起的时候，会产生一些很怪异的副作用。

大多数软件其实很无聊

把品牌故事和架构图都剥掉，绝大多数软件无聊得惊人：这边一个表单，那边一个 API 端点，撒点权限校验、计算逻辑、工作流，再加个数据库。要扛规模就上个队列——或者你只是想显得有追求。

说得难听点，多数软件就是个包装过的电子表格。

可生产这些东西的过程，偏偏能把普通人变成 B 级反派。项目永远不够快；计划必须随时为突发变化让路；每一个新功能都是"就是它了"——当然不是上一个冲刺里那个本该"就是它了"的功能。

总有人在担心：它能跑通吗？能扛住吗？我们够快吗？还是说我们压根就不该做这件事？

想法和落地之间，几乎没有摩擦

怪就怪在，上面这些问题在技术上几乎都成立。这恰恰是麻烦的来源：从一个想法到把它做出来，中间几乎没有什么天然的阻力。

盖房子就不一样。你要是打到一半忽然决定把厨房挪到楼对面，所有人立刻明白这里有个代价——板材切了，管路铺了，得把已经固定的东西拆开返工。代价是物理性的，没有谁能假装它不存在。

软件里，这些代价藏在人的脑子里，藏在那些本来就很难推理清楚的系统里。在软件里移动厨房看起来像"一个小改动"。工作是照样有代价的，只是花销悄无声息地累积：上下文频繁切换、回归风险、架构慢慢被侵蚀，最后落到丢掉势头、忘掉假设、以及开不完的"对齐"会议。

不管真实复杂度是多少，"这次改动是白送的"这句话都太容易说出口，因为看不到木屑和废料。更糟的是——改软件有时候真的可以很便宜。

一个有用的调整可能真的只花一小时；另一个看起来一样简单的要求，却能在整个系统里引发连锁失败。这种不透明养成了一个危险习惯：任何"超快的酷点子"都会带着紧急标签进入路线图。

有人在会上冒出个想法，而这个想法距离落地几乎没有阻力。这个界面能不能换个逻辑？商业模式能不能改？要不要追另一类客户？要不要再加一套工作流？干脆自己造个事件系统？

答案基本都是某个变体："当然，可以啊。"

从"可以"到"为什么还没做完"

渐渐地，"可以"变成了"应该"，"应该"变成了"为什么还没做完？"

软件就是从这一步开始对人大脑动手的。因为什么都能很快，所以什么都很紧急；因为理论上的上限可以巨大，所以每个决定都显得很战略。

每个技术选型都会变成意识形态之争，因为同一个问题有几十种看起来都成立的解法；每次变慢都像一场危机，因为据说某个地方有人跑得更快。这个行业几乎没有任何天然机制会告诉你：到此为止了。

软件里也没有一个明确的"完成"定义。木匠总会放下锤子，因为柜子已经立在那了；软件却永远可以更好。按钮还能更好，查询还能更快，抽象还能更干净，引导流程还能转化更多，基础设施还能再扩。产品可以进邻接市场，定价可以调，整个公司也可以宣布找到了更赚钱的方向。

重点在于：只要你愿意，手边永远还有一个拉杆。

我猜这也是软件组织容易神经质的原因之一——身边全是拉杆，而人被拉杆围着，早晚会去拉。

有时候是因为真出了问题；有时候只是害怕，是董事会在要增长，是竞争对手发了新东西，是这个月数据太平，或者干脆没人知道还能干什么。

换个说法就变成了优点

一个每隔几天就换方向的创始人，会被说成"紧跟市场"；一个不停催进度的管理者，会被夸"执行力强"；一个又引入好几套新基础设施的工程师，会被认为"有规模意识"；一个因为转化率微跌就把能用界面推倒重建的产品团队，那叫"在迭代"；一个因为另一个品类突然时髦就放弃原有定位的公司，那叫"在转型"。

这些词有一部分是因为动机本身合理——确实有些时候该快，确实有些时候该转型，确实有时候架构该换。软件真正危险的地方，是它让人很容易把"存在一个可做的动作"和"必须去做这个动作"混为一谈。

而如果这还不够糟，钱会往整堆火上浇汽油。

很少有行业能让一小撮人坐在屋里敲几年代码——如今是"指挥 agent"——就真有可能做出值几亿美元的东西。这种可能性改变了"无聊工作"的情绪重量。你会看到理智的人为一颗按钮争论一小时，因为在那场对话深处，这颗按钮已经和一叠未来的钱绑在一起了。

一旦到了这一步，普通判断力就被扔出去喂狼了。工作不再关心这颗按钮有没有连到真正有用的东西，而是承载了人们对这家公司可能变成什么的全部期望。

复杂度趁虚而入，填上同一个缺口。软件特别擅长让复杂显得重要，因为复杂的系统能把普通问题包装得更严肃。

一个在数据库里存记录、让人编辑记录的普通应用，听起来平平无奇；而一个分布式、事件驱动、带服务网格和实时同步层的平台，听起来像是你在造 NORAD（北美防空司令部）。

有时候你确实需要那个复杂东西。大多数时候你大概不需要。但复杂系统会给人简单系统给不了的心理回报——它提供了一堆可以设计、辩论、拥有、优化、重写、画图、压测、并且高谈阔论的对象。

复杂度制造工作，工作制造重要感，重要感制造地位；过不了多久，这个系统的存在目的之一是支撑这套组织，而这套组织的存在目的之一是支撑这个系统。整件事自我强化，从内部看还特别难察觉。

我们试图 debug 一切

作者认为底下还有一层更深的吸引：软件给了我们不寻常的控制感。代码是少数几个地方之一，你可以把想要的东西描述得足够精确，然后机器会可靠地照做。现实的其他部分远没有那么配合。

现实杂乱又固执；软件却让人产生一种错觉：杂乱（不管是技术上的还是概念上的）只是一个等着被 debug 的问题。

于是我们开始 debug 软件周边的一切。增长慢，就改漏斗；客户困惑，就重做产品；开发慢，就改流程；流程慢，就换工具。公司吃力，就重组；要是还吃力（而且靠风投输血），那就转型。

永远还有下一个可以操作的变量。

到最后，公司本身也开始被当成软件来对待：永远可变、永远未完成、永远只差一次重构就能正常工作。疯狂就是从这里真正沉淀下来的，因为没人能让任何东西保持原样。

让东西保持原样，是一项被低估的工程能力。职业生涯走到某个阶段你会开始明白：相当一部分好工作，来自拒绝去动那些本来就干得好好的东西。数据库不是总要换掉，框架往往还够用，引导流程也不需要这周再重做一次。

架构不必为一亿用户预留，路线图不必因为某人被一条推文点燃就改写。产品不必变成平台，公司也不必每个季度重新发现一次自己的身份。有时候，那东西只需要安安静静待着、正常运转。

客户需要时间去找到产品，工程师需要时间去理解系统，生意需要时间才能长成生意。这些话听起来都不新鲜，但软件文化对"耐心"异常敌视：耐心看起来很像无所作为，而在一个痴迷于速度的行业里，无所作为很难被交代。所以我们制造活动来替代——发版、迭代、优化、转型、换平台、重新思考、重新发明，直到最初的问题被埋得几乎看不见。然后几年后，有人悄悄提议把最初那个简单东西重做一遍。

答案不是慢，是分寸

作者说他并不认为答案是"为了慢而慢"。那只是另一种意识形态，而这个行业最不缺的就是意识形态。

答案在于分寸：理解不是每个问题都生死攸关，不是每个点子都该进路线图，不是每个抽象都配存在；接受不是每次变慢都需要干预，不是每个对手都重要，不是每份软件都要长成平台，也不是每家公司都得去追求统治世界。

再说一遍那个判断：尽管装饰了这么多，大多数软件依然只是个包装过的电子表格。这不是在骂人——电子表格很有用，而真正有用的软件已经够了。

也许我们都会清醒一点，只要记得自己到底在干什么：造工具，让自己和他人的日子好过一点，而不是在玛格丽特维尔里耗着，折腾那些不需要被折腾的东西。