应对基本和偶然的复杂性

软件实体的本质是互锁概念的构建：数据集，数据项之间的关系，算法和功能调用。这个本质是抽象的，因为在许多不同的表示形式下，概念构造都是相同的。尽管如此，它还是非常精确和详尽的。

我认为构建软件的难点在于对​​该概念结构的规范，设计和测试，而不是对其进行表示和测试表示形式的真实性的劳动。当然，我们仍然会犯语法错误。但是与大多数系统中的概念错误相比，它们是模糊的。

[返回]

奇怪的是，他在同一篇文章中还声称，没有任何个人进步可以在十年内产生10倍的增长。尽管从技术上讲这并不与他的艾哈迈德（Ahmdal）法则论证相抵触，但也有与“大多数”相抵触的说法。 （即至少一半）的复杂性是必不可少的/概念性的，目前尚不清楚为什么他也将这一要求也包括在内。

当布鲁克斯于1995年在《无银子弹再燃》（No Silver Bullet Refireed）上重新审视自己的论文时，他声称自己是正确的，使用了他在1986年提出的三项主张中的最弱形式，即十年之内，没有任何一项改进会导致数量级的改进。但是，他确实重申了他在1986年提出的最强主张的形式，并在1995年再次提出了这一观点，他说这一次，没有任何一项技术改进可以使生产率实际提高2倍以上：

我的观点是，仅此而已，工作的偶然性或代表性部分现在减少到总数的一半或更少。由于该分数是一个事实问题，因此其值原则上可以通过度量确定。未能做到这一点，我的估计值可以通过了解更多和最新的估计值加以纠正。值得注意的是，没有任何人公开或私下写过断言意外部分高达9/10。

顺便说一句，我感到有趣的是，他说没有人对此9/10的数字提出异议。根据这篇文章的内容，我的日常工作会远远超过9/10。如果我想在1986年解决相同的问题，那么这个比例会很高，以至于人们不会＃39;甚至还没有想到过这个问题。作为在硬件上工作了十年的副作用，我所做的工作与某些人在1986年所面对的工作（微代码，为DOS编写的汇编和C语言）相差无几。将该工作也轻松置于9/10以上。

我觉得有趣的是，他引用了哈雷尔（Harel）的《咬银子弹》（Biting the Silver Bullet）的另一部分内容。从1992年开始，其中除其他事项外，认为数量级改进的十年期限是任意的。布鲁克斯对此的回应是

十年限制还有其他原因：对候选子弹的要求都具有一定的即时性。 。 。我们肯定会在未来40年中取得重大进展；在40年内增加一个数量级几乎不是神奇的。

但是布鲁克斯他在1995年重新讨论该论点时说了自己的话，如果9/10的复杂度是必不可少的，那么减少它就不可能获得超过一个数量级的改进，而且不会引起时间上的警告：

＆＃34; NSB＆＃34;无可争辩地认为，如果工作的偶然部分少于总数的9/10，将其缩小到零（这很神奇）将不会给生产力带来一个数量级的提高。

他的第一篇论文和1995年的后续论文都是有魅力的，并包含一种局部逻辑，如果您不认真考虑而忘记了该论文所说的其他内容，则每篇论文听起来都比较合理。 。就像原始人一样，一个学徒可能会争辩说这在技术上并不是不连贯的-毕竟布鲁克斯会说：

最多不超过9/10的复杂度是偶然的（如果我们忽略后来的1/2主张，这是阅读本文必须做的那种记忆/怀疑的暂停）

对于我们来说，在40年后消除100％的意外复杂性就不足为奇了

尽管从技术上讲这是一致的（再次，如果我们忽略不一致的部分），并且是可以提出的一组主张，但这意味着从1986年开始即40年（即2026年），从工具，语言或任何其他潜在的改进源来的任何形式的生产率提高几乎没有零空间是令人难以置信的。但这是荒谬的。如果我们看一下布鲁克斯的其他部分，散文并结合他们的推理，我们会发现其他不一致和荒谬之处。

[返回]

我们在这里看到的另一个问题是Brooks＆＃39;保险之间明确区分类别。基本与意外的复杂性。 ＆＃34;类型＆＃34;解决方案，例如语言vs.＆＃34;构建vs.购买＆＃34;等。

布鲁克斯（Brooks）承认“建造与购买”是攻击本质复杂性的一种途径。也许他会同意购买regexp软件包会降低基本的复杂性，因为这将使我避免将与编写解析器相关的所有概念放在脑海中以完成简单的任务。但是，如果我不是购买正则表达式，而是使用将它们捆绑到标准库中或以其他方式随该语言一起分发的语言，该怎么办？或者，如果不必将自己的并发原语捆绑到语言中，该怎么办？或者说，整个HTTP服务器呢？在图书馆可以购买的东西之间没有明显的区别。 （如今在许多情况下都是免费的）和捆绑到该语言中的语言，因此，在一种语言所提供的收益与可以买到的收益之间不能有明确的区分。但是，如果这里没有明线区别，那么就不可能说其中一个可以降低本质复杂性，而另一个则不能并保持本质区别和基本区别。意外的复杂性（在对Brooks的回应中，Harel反对在回应中存在明显的区别，而Brooks的回应是在事实上存在明确的区别，尽管他没有提供新的论点。 ）。

布鲁克斯反复坚持这些错误的区分意味着论文中的推理是不可组合的。正如我们在另一个脚注中已经看到的那样，如果您从文章的一部分进行推理，然后将其与文章的另一部分进行推理相结合，则很容易产生荒谬的结果，有时甚至产生矛盾。

我怀疑这是关于本质与偶然复杂性的讨论如此混乱的原因之一。布鲁克斯不仅含糊其词，而且实际上是自相矛盾的，因此没有而且不可能是一个连贯的外卖。迈克尔·费瑟斯（Michael Feathers）指出，人们通常无法正确识别本质的复杂性。就像他说的那样，一个人的本质复杂性是另一个人的偶然复杂性。这正是我们从这篇论文中所期望的，因为头脑中具有不同部分的人最终将获得不相容的观点。

[返回]

让我们任意使用Motorola 68k处理器和FP协处理器，该协处理器可以做200 kFLOPS作为参考，说明我们在消费类CPU中可能有多少电量（FLOPS是一个不好的指标，原因有很多，但这仅仅是来了解获得1个CPU年的计算资源将需要什么，布鲁克斯本人使用MIPS作为术语，就好像它有意义。相比之下，Cray-2可以达到1.9 GFLOPS，或者大约是10000倍的性能（我想如果做一个可比较的比较而不是使用不可比拟的GFLOPS数值，实际上要少一些，但在这里要宽泛一些）。一年中有5分钟的时间为525600/5 = 105120，因此要在5分钟内获得1 CPU年的计算价值，我们每个查询需要105120/10000 = 10 Cray-2，不包括跨Cray-2汇总结果的开销。

认为一家消费类软件公司在1986年将拥有足够多的Cray-2来允许任何随机程序员在需要进行数据分析时快速运行CPU年价值的查询是不合理的。一位消息人士称，在该机器的整个使用寿命（1985年至1990年）中，共生产了27架Cray-2。即使我的老板所有这些都是在1986年创建的，但这仍然不足以允许我在2020年使用这种临时查询功能。

[返回]

在这种特定情况下，我敢肯定有人会说Visual Studio在2000年相当不错，并且在速度较慢的计算机上运行（可以说调试器比当前版本要好）。但是在Linux上没有可比的工具，在类似于VSCode的易于学习的编程编辑器空间中，也没有任何可与今天的选项相提并论的东西，它提供特定于编程的功能（而不是强大的版本）而不是成熟的IDE。 [返回]

顺便说一句，这并不是在1955年才发生的。我与本世纪告诉我汇编语言与任何高级语言一样高效的人们一起工作。这对于几乎每个博客读者来说都是荒谬的，但是如果您与花一整天编写微代码或汇编代码的人交谈，您有时会遇到一个相信这一点的人。

认为您个人使用的工具好用就容易陷入陷阱。

[返回]