尽管我在上文中将那些导致系统越来越复杂的驱动力描述为不可抵挡的力量,但是我们还不至于束手无策。实际上,我们也进行了一些抗争。重要的是,在奋力抗争的过程中,我们看出了它们的“真正实力”,并洞晓了根除它们的难度。
以下策略似乎可以让技术系统变得有序且有逻辑。针对不同的系统,如果我们能够采用不同的方式去构建、设计、修改和重建的话,那么,对技术的控制或许真的可以实现。例如,我们可以尝试解耦某些系统,将它们拆解为更小的单位,以保证它们的相对简单性和可管理性。拥有物理学背景的社会学家、微软研究院首席研究员邓肯·沃茨(Duncan Watts)指出,在金融领域,解决由复杂性导致的崩溃故障的方法之一,是直接消除耦合复杂性。 [67] 这就好比,如果某家公司的规模已经变得太过庞大,且预期其失败会造成级联式冲击,那么就必须对它进行拆分,或缩小其规模。
其他学者也讨论过类似的问题:怎样才能让一个大型系统的互操作性达到最佳水平。 [68] 这里所说的最佳水平是指,系统既能运行良好,又不会因高度的不可预测性而产生负面效应;也就是说,我们的目标应该是创造最佳水平的互操作性,而不是最大限度的互操作性。当然,这个目标不是那么容易就能实现的。想到是一回事,做到又是另一回事。实现这个目标的方法之一是坚持使用特定的设计原则,将可理解性和模块化内置于我们的设计中。
我在前文中已经阐述过,当一个系统具有高度的互联性时,我们便很难将其拆解,也就很难探究其内部发生的一切。但是,在大型系统中,确实可能存在这样的情况:某些部分之间的互联性远强于它们与其他部分之间的互联性。换句话说,系统中存在若干模块,而每个模块由若干“部分”紧密互联而成,并在一定程度上保持独立。我们常在生物学中见到这样的模块,它们皆包含了若干“行动一致”的“部分”。植物的线粒体和人体的心脏皆是如此。当然,这些模块通过别的身体器官和化学信号,以及其他方式,和系统其他部分保持着紧密的联系,所以我绝不建议人们进行心脏摘除手术。不过,这些模块又是相对独立的,即使不借助系统的整体功能,也可以被理解。
在技术系统中,我们同样可以观察到模块化现象。当一个软件拥有多个独立的功能或部分时;当你交替使用不同的应用程序来完成同一项工作时 ;当你分析《美国联邦法规》中那些相对独立的部分时,你都可以看到模块化的身影。模块化遵循了抽象的原则,实质是通过将系统拆解为若干部分,从而在一定程度上实现对复杂性的管理。
然而,从单个模块入手去理解系统,或者在单个模块的基础上构建系统,也并非总能让我们如愿以偿。如果每个模块都是多向输入和多向输出的话,那么当它们关联在一起时,系统的行为很可能仍是令人难以理解或无法预测的。最终结果很可能是“组合爆炸”:由于潜在的、不同的相互作用太多,模块数量很快就会超出我们的处理能力。例如,假设系统中的每个模块都分别具有6个不同的输入路径和输出路径,同时这个系统拥有10个模块,那么将所有这些模块关联到一起的方法将比整个宇宙中的恒星还要多。 [69]
在能够进行严格监管的领域里,例如,在金融系统中,或是在企业构架方面,找到理想的互操作性水平或加强模块化,是有可能实现的。我们可以规定,当机构达到一定规模时就必须进行拆分。然而,事与愿违,在大多数其他类型的技术系统中,各部分之间的互联通常只会继续猛增。当系统规模相对较小时,我们尚能进行模块化处理或分段构建,但是随着技术的发展,这种边界清晰的处理方式将变得越来越不可行。在社会压力和系统传统结构的共同作用下,我们不得不继续强化系统之间的相互联系,以致它们越来越难被分解。因此,尽管我们渴望简单,但现实却背道而驰。
虽然我们也可以尝试构建一些设计得更合理的系统,但这种方法只能在一段时期内行之有效。例如,现在业已出现的“计算机科学和工程实践” [70] ,其实质是“工程卫生学”,可以大大减弱系统的复杂性,比如避免计算机程序出现某些类型的变量。如果丰田公司采取了这种做法,那么其汽车系统的整体复杂性就会减弱很多。此外,专业软件通常也会包含一些能够降低代码错误率的设定。这些方法能够将每千行代码的错误率降低至6%,而这显然是一个极低的数字。 [71] 当人们共同构建、操作和维护复杂的技术系统时,管理团队的一些特殊操作将有助于减少系统问题。但是从长期来看,吸积、交互和边界情况最终会使这些简化工作成为徒劳。
随着时间的推移,系统渐渐变得复杂;而面对这些复杂系统,我们的大脑也渐渐无能为力。无论是互联网,还是大型基础设施,要想从整体上理解它们,已经不可能了。
那么,为什么必然会产生这样的结果呢?在接下来的一章中,我们将讨论人类理解能力的社会极限和生物极限:无论有多么努力,我们的大脑和社会在面对这些复杂系统时的表现都不会太好。