一个装修队要把厨房挪到房子另一头，工头当场就能报出返工的木料、水管和工时——成本看得见摸得着。软件世界里同样一句"把这个流程改一下"，看起来是免费的。没有木屑，没有拆墙的噪音，但成本没有消失，只是藏进了上下文切换、回归测试和一轮又一轮"对齐会议"里。一篇最近在Hacker News上冒出来的博客《Software Drives People Insane》把这套隐藏成本讲成了行业黑话：软件不是让人变蠢，是让"能做"这件事几乎没有摩擦，于是"能做"很快滑成了"应该做"。
隐藏成本，原来是有数字的
原文靠的是作者自己"看过很多次"的观察，没有一个数字。把这套直觉拿去对照公开数据，发现它站得住：
- PMI的项目管理报告显示，52%的项目经历过范围蔓延或失控的范围变更，五年前这个比例是43%。
- 一项针对开发者的纵向研究发现，技术债平均吃掉开发者23%的工作时间，而四分之一的技术债处理，反而会引入新的技术债。
- 微软的研究里，62%的开发者认为同事或管理者造成的频繁任务切换是显著问题；另一项研究测算，开发者每天约59%的任务发生切换，其中29%被打断后再没被捡回来。
- NASA的缺陷检查数据显示，代码审查阶段发现并修复一个缺陷平均花1.1小时，同样的缺陷留到正式测试阶段才发现，要花5到17小时。
这组数字回答了原文没回答的问题：软件的返工成本不是不存在，只是被拆成很多份，分散藏在不同时间点、不同人的日程里，谁都感觉不到疼。
谁在被这套机制折腾
工程师首当其冲。他们承受着频繁改需求和上下文切换，却要在绩效叙事里把这些包装成"响应迅速"。产品经理和创始人站在另一头："迭代""转型""响应市场"这套词汇，给随手改主意提供了合法外衣，回头看很难分清哪句是真判断，哪句是事后找的理由。管理层和董事会承受增长焦虑，拉杠杆变成最容易被看见的"管理动作"——哪怕拉错了杠杆。
谷歌对上千个项目和数千份开发者调查的研究，补上了另一块拼图：架构复杂度越高，团队花在修bug而不是做新功能上的代码量，统计上显著更多。复杂系统给人一种"我们在干大事"的错觉，实际上是在给未来的自己欠债。
但这锅，软件背得冤不冤
Hacker News式的批评其实很扎实：把疯狂归咎于"软件"本身，更像是把风投驱动的增长焦虑、弱产品管理和地位竞争的锅，甩给了一个中性的工具。同样的病征，咨询公司、政治项目、大型基建工程里都能找到——预算总能被追加，方案总能被推翻，只是软件因为改起来"看着便宜"，把这套毛病放大到了极致。
原文里"大多数软件就是加了皮的电子表格"这句话很有力，但不精确。权限、并发、故障恢复、可审计性、安全、迁移——这些才是真正难啃的部分，一并归为"电子表格的皮"，低估了工程本身的重量。
原文倡导的"比例感"听起来很对，却没给出操作标准：什么时候该拉杠杆，什么时候该忍住不拉？"留着不动"说得轻巧，可有时候不动手才是真正的懒惰，或者是另一种意识形态——用"克制"当借口，回避该做的重构。
软件让改主意变得几乎零成本，却让看清代价变得极其困难。
一张能落地的检查表，比"保持克制"更有用
道德劝诫解决不了问题，量化指标可以。把原文的直觉翻译成几个可以追踪的数字，一个团队至少能问自己：
- 结论.范围变更占比、跨组件改动比例、返工工时，这三个数字连续几个季度往上走，说明公司在"活动"而不是"进展"，该停下来问一句为什么，而不是继续加功能。
- 风险.如果团队把"留着不动"直接当政策，同样危险——技术债、安全补丁、真正的架构瓶颈，不会因为没人碰它就自动消失。
孔子说"过犹不及"，放在这里刚好合适：软件行业的病，从来不是"变化太多"或"变化太少"，而是没有一个像木匠钉好柜子那样清楚的止损点，让人知道什么时候该收工。