我有个小理论:软件会把人逼疯。不是每三十分钟就得洗手那种,而是围绕软件的条件容易让本来正常的人失去分寸感。见得多了,我不觉得这全是性格问题。软件把速度、金钱、复杂性、抽象和几乎无限改主意的自由揉在一起,单看还好,合起来就冒出古怪副作用。多数软件剥掉品牌和架构图后很无聊:一个表单、一个接口,加点权限和数据库。
正文
我有个小理论:软件会把人逼疯。
不是霍华德·休斯那种每三十分钟洗一次手的方式,而是软件周边的环境特别擅长让本来正常的人失去分寸感。
这种场面我见得太多了,从太多角度看过,所以我不觉得这纯粹是性格问题。
软件把速度、金钱、复杂性、抽象,以及几乎无限的反悔自由揉在一起。单拿出来每一样都好对付,凑到一起就会产生一些非常诡异的副作用。
大多数软件,剥掉品牌和架构图之后,其实无聊得很。这儿一个表单,那儿一个 API 接口,撒点权限、计算、工作流,再加个数据库。要扩容就加个队列(或者你想找点刺激)。
但残酷的事实是:大多数软件不过是镀了金的电子表格。
然而生产这些东西的过程,却能把完全普通的成年人变成 B 级片里的邦德反派。项目永远不够快,计划必须随时为突发变化让路,而每一个新功能都是那个将成为「那个」的功能(但肯定不是上一个冲刺里本该成为「那个」的那个)。
总有人担心它能不能跑通、能不能扩容、我们够不够快,或者干脆该不该做点别的。
软件的诡异之处在于,这些想法很多在技术上真的可行。这正是问题的一部分:从想法到实现之间几乎没有天然摩擦。你要是盖房子,框架打到一半有人说厨房该挪到楼另一头,所有人都立刻明白这个决定有代价。
木板已经裁了,管道已经铺了,得把装好的东西拆开。代价是物理性的,没人能假装它不存在。软件里,这份代价藏在人脑里,藏在通常本来就很难讲清楚的系统里。
在软件里挪厨房看起来可能是个「小改动」。活儿一样费劲,但真正的开销悄悄累积。上下文切换、回归风险、架构建模的侵蚀,最后变成丧失的动力、被遗忘的假设,和无穷无尽「对齐一下」的会议。
不管实际复杂度如何,人们很容易假装这个改动是免费的,因为看不见灰尘和碎屑。更糟的是,改软件有时候真的可以很便宜。
一个有用的调整可能真的一小时就能搞定,而另一个看起来一样简单的需求却可能波及整个系统造成故障。这种不透明催生了一个危险的习惯:每个「超快的酷点子」都被加进路线图,而且常常带着紧迫性。
有人在会上冒出一个想法,从想法到现实之间往往阻力极小。这个界面能不能换个做法?能不能改商业模式、去追另一个客户群、再加一套工作流、还是自己造一套事件系统?
答案几乎总是某种形式的「当然,可以啊」。
最后,「可以」变成「应该」,「应该」变成「怎么还没做完?」这就是软件开始对人脑做怪事的地方。一切都变得紧急,因为一切都可以很快;每个决定都显得有战略意义,因为理论上的上行空间可以巨大。
每个技术选择还都变成意识形态,因为同一个问题有几十种看起来合理的解法。每次变慢都像是危机,因为据说别处的某人跑得更快。这个行业几乎没有天然机制来告诉人们什么时候够了。
软件里也没有真正明确的「做完」的定义(我不太情愿地分享《社交网络》里的一段片段,它把这态度演得很好)。
木匠最终会放下锤子,因为柜子已经在那儿了;软件却永远可以更好。按钮可以更好,查询可以更快,抽象可以更干净,引导流程可以提高转化,基础设施可以扩得更远。产品可以扩展到相邻市场,定价可以改,整个公司也可以决定自己发现了更赚钱的方向。
重点是:只要你想,总有一根拉杆就在手边。
我觉得这是软件组织变得如此神经质的原因之一:它们被拉杆包围,而被拉杆包围的人最终会开始拉。
有时候拉是因为确实出了问题。另一些时候拉,是因为害怕、因为董事会要增长、因为竞争对手发了新东西、因为这个月数据持平、或者因为没人知道还能干什么。
创始人隔几天换个方向,会被美化成「对市场做出反应」。经理不断逼人加快,被认为执行力强;工程师塞进几个新的基础设施组件,会被称赞有扩展性思维。产品团队因为转化率略降就重做能用的界面,叫迭代;公司因为另一个品类突然时髦就抛弃原有定位,叫转型。
这些说法有些存在是有道理的,动机本身也正当。有些时候你确实该快,确实该转型,架构确实该改。软件危险的地方在于,太容易把「存在一个可采取的行动」和「需要采取这个行动」搞混。
更糟的是,钱还会往上浇汽油。
很少有行业能让一小撮人坐在屋里敲几年键盘(现在可能是指挥几个 agent),就有望做出价值上亿美元的东西。这种可能性改变了那些本来很平凡的工作(对非极客而言)的情绪重量。
你可以看着理智的人为一个按钮争论一小时,因为在这场对话深处,这个按钮已经跟未来的一堆钱绑在了一起。
一旦这样,平常的判断力就被扔去喂狼。工作不再是这个按钮是否连着有用的东西,而是承载着人们对这家公司可能变成什么的一切期望。
复杂性趁虚而入填上同一个缺口。软件特别擅长让复杂性显得重要,因为复杂的系统让普通问题看起来更严重。
一个在数据库里存记录、让人编辑的无聊应用听起来不怎么样,而一个带服务网格和实时同步层的分布式事件驱动平台听起来像在造北美防空司令部。
有时候你确实需要复杂的东西。多数时候,你大概不需要。但复杂系统提供简单系统给不了的心理回报:有东西可设计、可争论、可拥有、可优化、可重写、可画图、可压测、可谈论。
复杂性创造工作,工作创造重要感。重要感创造地位,不久之后,系统的存在部分是为了支撑组织,而组织的存在部分是为了支撑系统。整个东西自我强化,从内部很难察觉。
我猜这一切底下还有一层更深的吸引力。软件给了我们异常多的控制感,因为代码是为数不多的地方,你可以足够精确地描述你要什么,然后让机器可靠地照做。现实的其他部分远没那么配合。
现实又乱又犟,而软件给了我们一种印象:乱——无论是技术上还是概念上——是一个等着被调试的问题。
于是我们开始试图调试软件周围的一切。增长慢,就改漏斗;客户困惑,就重做产品;开发慢,就改流程;流程慢,就换工具。公司挣扎,就重组;要是还挣扎(而且靠风投活着),那就转型。
总有另一个变量可以摆弄。
最终公司本身也开始被当成软件对待:永远可变、永远未完成、永远差一次重构就能正常运转。疯狂就在这儿真正扎根,因为没人能对任何东西撒手不管。
不碰东西是被低估的工程能力。职业生涯某个时点你会开始明白,相当多的好活儿来自拒绝去动那些本来就在好好干活的东西。数据库不必总被替换,框架往往挺好,引导流程这周不需要再重做一次。
架构不需要为十亿用户做预案,路线图不需要因为有人在推特上兴奋了一下就改。产品不需要变成平台,公司不需要每季度重新发现自己的身份。有时候东西只需要待在那儿,正常工作。
客户常常需要时间才能找到产品,工程师需要时间才能理解系统,生意需要时间才能成为生意。这些听着都不深刻,但软件文化对耐心异常敌视。耐心看起来可疑地像不作为,而不作为在一个痴迷速度的行业里很难辩护。
所以我们改成制造活动。我们发布、迭代、优化、转型、换平台、重新思考、重新发明,直到最初的问题在我们叠加的一切之下几乎看不见。然后几年后,有人悄悄提议重建最初那个简单的东西(往往还指着自己那点自以为是的智慧,说正是它带来了这个洞见)。
我不认为答案是为了慢而慢。那只会是另一种意识形态,而软件已经够多这种玩意儿了。答案是分寸。
它意味着明白不是每个问题都是生死攸关,不是每个想法都该进路线图,不是每个抽象都配存在。它意味着接受不是每次变慢都需要介入,不是每个竞争对手都重要,不是每款软件都要变成平台。也意味着记住不是每家公司都要去征服世界。
我再说一遍:尽管有这么多装饰,大多数软件仍然是镀了金的电子表格。这不是骂人。电子表格有用,而(真的)有用的软件就够了。
但如果我们记得自己在干什么——造工具让自己和他人的生活更轻松——也许大家都能清醒一点。而不是在玛格丽塔小镇里虚度光阴,摆弄那些不需要被摆弄的破玩意儿。
评论
社区普遍共鸣软件开发环境易诱发非理性,但在归因上分歧明显:多数人指向脱离用户的封闭开发、过度设计或普通企业通病,少数人深究技术栈更迭与算力结构。
认为脱离用户现实的封闭开发是致疯主因
- 开发者若被项目经理隔绝、不与客户定期接触,自由发散的效应会失控;编程本身在只追求更好的微世界中容易让人脱离现实逐渐发疯。(较多人) > 开发者若被要求定期与用户接触,文中描述的那种自由失控效应就会被大幅抑制(@bob1029)
认为过度设计与错把工具当现实征服是核心病症
- 技术领导者常把市场对抽象模型的奖赏误认为征服了现实领域而变得自大;用复杂架构包装简单的数据库操作,是资本涌入后软件丧失克制艺术的表现;用户其实只想要核心功能稳定,多数花哨设计是累赘。(较多人) > 你究竟是征服了商业地产,还是只造了个方便的排期应用?(@randusername)
认为这不过是普通企业病或互联网病而非软件独有
- 文中所说的疯狂在任何行业都存在,不过是人人想抢功、找茬的企业内耗;也有人说根源是互联网让人变蠢,而非软件本身;企业强制的策略扫描器和“一切皆紧急”的高管文化同样致疯。(较多人) > 作者描述的疯狂在我看来就是普通公司的扯皮,做广告或塑料杯也一样(@dkarl)
认为技术栈频繁更迭与算力结构变化是深层根源
- 过去团队小、依赖稳定,精力在算法;如今技术频繁更迭让团队陷于选型和重构,几十人做简单业务却效率低下;算力爆炸带来新自由也带来垄断夹击,缺乏新约束会致疯。(少数人) > 过去几人用稳定依赖做核心系统,如今大团队把精力耗在技术栈更迭上做简单业务(@hliyan)
有价值的补充
- 懂得“不随意改动”是被低估的工程能力,克制本身就是对抗疯狂的解药(@iamcalledrob)。
- 软件无所不能的特质会放大程序员的“工程师自大症”,因为造杠杆的人易觉得自己不亚于造物(@Apocryphon)。
- 认知封闭的聊天回音室缺乏绝对锚点,一切主观自我确认,会让人滑出控制(@FiddlerClamp)。