返回资讯中心
外部精选
软件工程
#开发者实时流

大型系统为何在开发中瓦解:委员会如何发明

来源标题:How Do Committees Invent?

软件工程经典论文《委员会如何发明》指出,大型系统在开发过程中比小型系统更容易出现结构性瓦解,文章以过去十余年的大型军事信息系统为例说明这一现象,并探讨“系统管理”活动如何应对这一趋势。

Hacker News 最新Bluestein2026/11/7 · 5 天前21 分钟阅读

以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

考虑一下正在运行、用于解决问题的计算机系统。从较高层次来看,它由三部分组成:硬件、系统软件和应用程序。(见图3b。)与这些子系统相对应的是各自的设计者:计算机制造商的工程师、其系统程序员,以及用户的应用程序员。(那些系统硬件与软件倾向于协作而非仅仅相互容忍的罕见情形,往往与程序员和工程师之间也保持着类似关系的制造商有关。)大型系统的结构在开发过程中往往会瓦解,而且在性质上比小型系统更为严重。将这一观察应用于过去十几年的大型军事信息系统时,其表现尤为明显;这些系统是人类心智所设计出的最复杂对象之一。一种称为“系统管理”的活动已应运而生,部分原因正是为了应对系统这种易于瓦解的倾向。让我们考察一下我们在此提出的概念对系统管理的效用。为什么大型系统会瓦解?这一过程似乎分三步发生,其中前两步是可控的,第三步则是我们同态关系的直接结果。让我们首先考察设计工作中人员过度膨胀的倾向。初始设计者——即其初步设计概念影响设计工作组织方式的那个人——有一种自然的诱惑:当系统的表观复杂度接近其理解能力的极限时,他就会把任务分派出去。这是设计过程中的转折点。要么他努力将系统简化到可理解的程度并取得成功,要么他失去对系统的控制。如果存在进度压力并且需要管理预算,结果几乎是可以预见的。管理者知道,如果他没有动用全部资源却错过了进度,就很容易被指责为管理不善。这种认识给初始设计者带来了强大压力,他可能宁愿与设计难题搏斗,也不愿通过分派任务将其割裂,但他被弄得觉得冒险的代价太高,不能冒这个险。因此,他被迫分派任务,以便投入更多资源。下面的案例说明了管理者所处环境可能与正在设计的系统的完整性发生冲突的另一种但相关的方式。管理者必须将一项关键而困难的设计任务分包出去。他有两个承包商可选:一个是小型新组织,提出了一种直觉上很有吸引力的方法,要价远低于预算;另一个是成立已久但作风传统的机构,索要更为“现实”的费用。他知道,如果那个聪明的新组织未能拿出足够成果,他会被指责为管理不善;而如果老牌机构失败,那反而证明问题确实困难。这里的困难是什么?很大一部分与因传统会计理论而产生的资源计量推理方式有关。根据这种理论,资源的单位是美元,所有资源都必须使用可换算为美元的计量单位来衡量。如果资源是人力,计量单位就是每个人工作的小时数乘以其小时成本,再对整个劳动力求和。这一计算背后的一个谬误是线性假设,即两个人工作一年或一百个人工作一周(按每人相同小时成本计)是等价值的资源。假定两个人与一百个人无法在相同的组织结构中工作(这一点直觉上显而易见,下文将讨论),我们的同态关系表明,他们不会设计出相似的系统;因此,他们努力的价值甚至可能无法比较。根据经验我们知道,如果两个人选得合适并且经受住了考验,他们会给我们一个更好的系统。那些可能足以应付削土豆和砌砖墙的假设,在涉及系统设计时却不成立。帕金森定律[4]在设计工作过度分配中起着重要作用。只要管理者的威望和权力与他的预算规模挂钩,他就会有动力扩大自己的组织。这在系统设计活动的管理中是一种不适当的动机。当然,一旦组织存在,它就会被使用。如今存在的许多设计糟糕的系统背后,可能最大的单一共同因素就是有一个需要工作的设计组织可供使用。系统设计瓦解的第二步——设计组织沟通结构的碎片化——在分派一开始就开始了。初等概率论告诉我们,一个组织中可能的沟通路径数量大约是组织人数的平方的一半。即使在规模适中的组织中,为了让人能完成一些“工作”,也有必要限制沟通。研究能够使设计者之间更高效沟通的技术,将在系统管理技术中扮演极其重要的角色。常见的管理实践对代表军事式组织行政结构的线图复杂度施加了某些数值约束。具体来说,每个人最多只能有一个上级,并且最多大约有七个下属。由于组织规程会沿指挥线限制沟通,组织的沟通结构将类似于其行政结构。这就是为什么军事式组织

(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →