1986 年那篇《没有银弹》，其实是一篇论证极其克制的文章。重读它，你会发现布鲁克斯没有否认技术进步——他列举了当时所有的时髦工具：高级语言、分时系统、统一编程环境，承认它们都带来了可观的进步。他否认的只是：这些进步都是一次性的「偶然困难的局部清缴」，而不是生产力数量级的跃迁。
为了讲清楚为什么本质困难无法被工具触碰，他给出了软件的四条固有属性。这四条今天读来依然锋利：
- 复杂性：软件是人类建造过的最复杂的物体。一座桥梁有几十万个零件，但同类零件大量重复；一个大型软件系统里没有两个完全相同的模块，规模一大，复杂度按组合数爆炸。
- 随附性（conformity）：软件没有自己的物理定律，它必须去迁就人类社会任意的、历史形成的规则——银行系统要符合会计惯例，税务系统要符合税法，而税法明年可能就变。这部分规则毫无道理可讲，但一行都不能错。
- 易变性：桥建好了就没人想着「把桥重构一下，把第三根柱子改成可插拔的」。软件被使用就必然被提新需求，而改动会引发连锁改动。
- 不可见性：建筑有图纸，电路有板图，软件没有天然的直观形态。它看不见摸不着，你没法绕着它走一圈获得整体感。
这四条属性界定了「必要复杂度」的领土：它们是问题自带的，不是工具带来的。布鲁克斯由此断言：任何瞄准本质困难的银弹都不存在，未来的进步只能继续来自偶然困难的削减。
四十年里，人们真的信过无数次「这次是银弹」
布鲁克斯的冷水没能浇灭行业的热情，因为「让不会编程的人也能指挥计算机」这块蛋糕实在太诱人。历史上一串闪亮的名字，今天听来都像银弹宣言：
1959 年，COBOL。这门语言被刻意设计成像英语：ADD TAX TO PRICE。设计者的梦想是让经理们直接写代码。结果 COBOL 确实统治了商业计算半个世纪，但写它的依然是专业程序员——英语式的语法，骗过了外行，骗不过机器：写 ADD TAX TO PRICE 之前，你还是得想清楚变量、类型和控制流，这些才是难点，而这些难点被漂亮地伪装掉了。
1980 年代，第四代语言和 CASE 工具。厂商承诺「画流程图自动生成系统，从此不需要程序员」。大批企业买了单，大批项目死在了交付前。问题不在工具好坏，在于需求本身会生长：图能表达正常流程，表达不了「对账差一分钱时该怎么追溯」这种长在业务褶皱里的规则。
二十一世纪初，Scratch。麻省理工学院的团队 2003 年前后开始研发图形化编程，2007 年正式公开：拖积木代替写语句。这次是真实成功——但请注意它的成功范围：教孩子表达逻辑。它降低的是「键盘语法」这个最浅的偶然困难，而孩子们用它写的，依然是他们自己构思的程序。一旦涉及复杂规则，积木图照样会乱成一团。
注意这三十年潮起潮落的共同模式：每一次，人们都试图用「更友好的表达形式」绕过翻译层，每一次都失败了。失败的原因不是形式不够友好，而是缺了翻译层下游的那个东西——一个能接住模糊意图、自己补齐细节的翻译者。形式再友好，「把需求精确化」这活儿还是得人来干。
大白话：以前的「自然语言编程」，是给了你一支英文笔，作文还得自己写。缺的不是笔，是代笔的人。
所以布鲁克斯是对的，而且比他自己知道的更对：他论证的是「意图到代码的这段路必须有专人翻译」。四十年里这个论证无懈可击——直到翻译这件事本身，被证明可以不由人来做。
下一章，看看 2020 年代到底什么东西变了。