软件公司为何倒闭

免责声明

本文是我个人对软件公司消亡原因的看法。本文并非科学论文，因此许多陈述有意大胆直接，以使文本简短。我尽力根据自己的观察和现有资料提出了结论，但我并非专业的社会学家、生态学家或商业理论家，可能完全错误。此外，我没有数据来支持这些陈述，因此请持怀疑态度对待。

除非另有说明，所有引文均来自《崩溃：社会如何选择失败或成功》。

“凡欲成为哲学家者，必先学会不被荒谬吓倒。”
— 伯特兰·罗素
“那些不能铭记过去的人，注定要重蹈覆辙。”
- 乔治·桑塔亚那

沸腾的大锅

软件商业世界是一个沸腾的大锅。一些公司迅速成长，另一些几乎瞬间消失，还有一些，通常是大型公司，则缓慢停滞和衰落。软件行业几乎没有稳定性可言。曾经占据市场主导地位的公司（如网景）如今已不复存在。今天位居榜首的公司在二十年前还未出现。似乎只有极少数公司能够成功地长期维持下去。

这让我思考：是什么原因让成功的软件公司几乎在一夜之间消失殆尽？原因不可能是纯粹的技术性的。自计算机被发明以来，其运行原理并未改变。它们只是“过于复杂的音乐盒”，每年只是变得更快、更节能。构建软件的最基本原理也未发生太大变化（每个程序都是序列、选择和迭代的组合）。甚至最近流行的函数式编程也可以追溯到1958年。一家软件公司由编写代码的人组成。如果技术基础总体稳定（量子计算机尚未普及），那么软件业务失败的原因必然是与人类相关的，换句话说，是社会性的。

公司与社会

我首先需要提出的问题是，软件公司是否可以被视为一个小社会，如果是，那么相同的规则是否适用。根据维基百科，“社会是一群持续进行社会互动的人，或一个共享相同空间或社会领土的大型社会群体，通常受相同的政治权威和主导文化期望的约束。社会以共享独特文化和制度的个体之间的关系模式（社会关系）为特征；一个特定的社会可以被描述为其组成成员之间所有这些关系的总和。”另一方面，公司的定义则相对谦逊，指出公司是“一个代表一群人（无论是自然人、法人还是两者的混合）的法律实体，具有特定目标。公司成员共享一个共同目的，并联合起来实现特定、声明的目标。”这两个定义，尽管表达方式不同，但在我看来却有显著的相似之处。社会和公司都

• 是人群（个体）；
• 占据一定的社会空间或领土（一个地点）；
• 受权威约束（管理结构）；
• 受文化期望约束（业务流程和行为准则）；
• 联合个体以实现共同目标（提供维持这些个体生存的手段）。

这些相似之处促使我寻找软件公司崩溃的可能社会原因。

一本阴郁的故事书

贾雷德·戴蒙德在他引人入胜的著作《崩溃：社会如何选择失败或成功》中，研究了多个经历过成功增长后迅速崩溃的古代文明。通过研究（其中包括）复活节岛、查科峡谷、玛雅或格陵兰北欧人等文明，他创建了一个五因素框架，结合了导致社会崩溃最具影响力的原因。戴蒙德提出的原因包括：

• 社会造成的环境破坏，表现为环境生产力低于维持人口所需的水平（主要是森林砍伐、水土流失、过度捕捞、过度捕鱼和水资源管理不善）；
• 影响粮食生产的气候变化；
• 敌对邻国的崛起对社会构成物理威胁；
• 社会所依赖的友好邻国的崩溃；
• 面对上述威胁时无法改变运营方式。

图1直观地表示了这一概念。红色表示社会无法控制的因素。蓝色表示社会可控制的因素。“友好邻国的崩溃”是一个社会可以通过帮助有需要的邻国来部分控制的因素。

这本书深刻的结论是，“一个社会的急剧衰落可能在其达到人口、财富和权力巅峰之后仅仅一二十年就开始。原因很简单：最大人口、财富、资源消耗和废物生产意味着最大的环境影响，接近影响超过资源的极限。”软件公司是否也会因同样的原因遭遇同样的命运？

异而同

在指出社会与公司之间的相似之处后，我得出结论，戴蒙德的框架可以用来解释软件公司的失败。图2展示了改编后的框架。

其中一些改编是直接且显而易见的，而另一些则需要下面提供的更多解释。

环境破坏

贾雷德·戴蒙德将环境破坏列为社会崩溃的主要罪魁祸首。其最常见的体现是森林砍伐导致的水土流失，或者更普遍地说是自然植被的破坏。这最终导致日益严重的食物短缺，引发饥饿、饥荒和内战。这让我思考，对于软件公司而言，“土壤”的等价物是什么。如果土壤能让作物生长，并带来食物，那么什么能为软件公司带来“食物”呢？软件供应商的“食物”是它们可以销售给客户的功能，而新功能就像庄稼在土壤中生长一样，在现有代码库中“生长”。这意味着水土流失的等价物是源代码侵蚀，伴随着文档和架构完整性等其他制品的侵蚀。这种类比在产品开发初期、首次发布之前并不成立，但在我看来，它在软件公司的大部分生命周期中是成立的。

被侵蚀的源代码难以理解、功能模糊、结构混乱，并且通常难以修改。就像一个社会每年需要在同一片土地上种植作物一样，软件公司需要通过修改现有代码库来反复调整其软件产品（以满足不断变化的市场需求）。在土壤侵蚀的情况下，每年种植的作物越来越少，所需的努力却越来越多。在代码库被侵蚀的情况下，每年交付的适应性改动越来越少，所需的努力却越来越多。如果这个过程继续下去，在某个时候，成本不可避免地会超过产生的价值。

戴蒙德描述的另一个密切相关的问题是水资源管理不善。没有优质的水，就不可能种植作物，但在软件开发中，水的等价物是什么？如果作物在土壤中因水而生长（阳光被认为是理所当然的），那么新功能和适应性改动在现有代码库中则因程序员而生长。开发者流失（表现为短缺或能力低下）意味着现有代码库中可以“生长”的功能数量有限甚至没有，就像水资源短缺或污染（例如盐碱化）会阻止真正的作物生长一样。开发者流失可能由不良的公司政策或糟糕的管理实践引起，但通常是由代码侵蚀引起的，因为最优秀的程序员最终会感到沮丧并离开，因为他们的基本需求未得到满足。开发者流失会加剧代码侵蚀，因为新入职者不熟悉代码库，倾向于简单地修补它以减轻引入新缺陷的风险。这种情况可能变成一个恶性循环。被侵蚀的代码库会首先促使最优秀的开发者离开。然后新入职者会进一步损害代码库，这又导致下一批留下的优秀程序员离开，依此类推。高流动率也可能损害公司的形象，降低招聘经验丰富的程序员的可能性（“实习生公司”综合症），并收紧如图3所示的死亡螺旋。

开发者流失还有一个隐藏的致命结果，那就是“单位变更”成本（一个新功能或适应性改动）的增长。让我们考虑一家雇用25名开发人员，每年能够交付假设的100个“单位变更”（新功能和适应性改动）的公司。我们还假设一名开发人员的成本是每年1000美元。每个“单位变更”的开发成本是1000美元 * 25/100 = 250美元。现在，让我们假设被侵蚀的代码库导致开发人员感到沮丧，其中五人离职。很有可能，离开的人是最优秀、最有效率的，因为他们拥有最多的选择。如果是这样，那么根据普莱斯定律，剩下的20名开发人员的生产力每年只有50个“单位变更”（而不是数字可能暗示的80个）。这将每个“单位变更”的开发成本改变为1000美元 * 20/50 = 400美元。让我们假设公司的收入与每年交付的“单位变更”成正比。考虑到更长的时间跨度，这是一个合理的假设，因为跟不上不断变化的需求会更难获得新客户，更容易失去现有客户。如果假设收入是每个“单位变更”1000美元，那么收入从1000*100 - 1000*25 = 75000美元下降到1000*50 - 1000*20 = 30000美元。这样的下降显然会引起管理层的注意，他们不会将其归因于能力、智力和智慧的损失（他们通常无法评估程序员的能力），而是归因于社会惰化，因为他们会认为20名程序员（又称“开发资源”）应该能够每年交付大约80个单位的变更。最常采取的行动是引入更严格的控制，通过引入更繁重的软件开发过程，并由更多的经理进行管理。这增加了总人口和成本，并导致社会不平等加剧，因为人员过多的管理层倾向于通过用更便宜的开发人员（通常通过外包）取代昂贵的开发人员来寻求节约。这使得代码库侵蚀得更多，恶性循环如 图4所示，闭合了。

戴蒙德认为，环境破坏是其他影响的促成因素和放大器。我也赞同这一观点，并认为代码库和开发者流失是一种促成因素，使软件公司更容易受到接下来描述的其他影响。

气候变化

戴蒙德讨论的社会崩溃的第二个原因是气候变化。通常，影响最大的变化是影响粮食生产的干旱。另一方面，对于格陵兰岛的北欧人来说，是被称为小冰河时代的全球变冷，这不仅降低了他们收获作物和饲养动物的能力，而且由于航行北大西洋变得困难，也中断了与欧洲大陆的贸易。在我看来，气候变化相当于我们在过去50年中能够观察到的技术转变。从大型机和终端时代，我们转向了工作站和服务器，然后又转向了Web和移动。这些转变给软件公司带来了压力，要求它们将其现有解决方案适应新的现实，就像气候变化要求调整旧的耕作和放牧方法以在新条件下繁荣发展一样。除了技术转变，法规变化也发挥类似作用，因为它们可以使整个经济部门几乎在一夜之间消失。

社会和软件公司都无法控制“气候变化”。它们只能对其做出反应。一个拥有肥沃土壤和清洁水盈余的社会，拥有更多的资源来成功适应新的气候。同理，一家拥有健康代码库和有能力程序员的软件公司，比其竞争对手更有机会适应新的技术形势，并因此而生存下来。

敌对邻国的崛起

敌对邻国的崛起对每个社会来说都是一个长期存在的威胁。凶猛“野蛮人”部落的入侵曾是过去危机和崩溃的原因。同样，竞争的加剧可能导致软件公司崩溃，如果它无法做出相应的回应。一个经典的例子是微软在第一次浏览器大战中击垮了网景。另一个例子可能是开源产品的崛起，这可能对整个行业造成“毁灭性”影响，例如Git的崛起，它抢占了可观的市场份额并重塑了整个行业。软件公司无法有效控制敌对邻居，除非它们将其收购。如果收购不可能，那么现有代码库的质量在公司生存中扮演着重要角色。一个拥有肥沃土壤和充足水源的社会可以生产更多的食物来养活士兵，从而可以负担更多的士兵来抵抗入侵。同样，一个拥有更健康代码库和熟练开发人员的软件公司，更有机会快速适应并跟上甚至超越敌对竞争对手。

友好邻国的崩溃

亨德森岛的人口是贾雷德·戴蒙德描述的友好邻国崩溃的受害者之一。亨德森岛人居住在太平洋中部一片贫瘠的土地上，主要依靠捕鱼为生，并依赖从另外两个太平洋岛屿——芒阿雷瓦和皮特凯恩——进口优质石材（用于制造工具和渔具）和木材（用于建造船只）。当进口因与亨德森岛人无关的原因停止后，该岛人口就失去了维持捕鱼的手段，并最终灭绝。

一家软件公司可能会因业务伙伴、供应商（例如，关键库供应商）甚至底层平台（Symbian、Windows Phone）的崩溃而受害。如果公司能够收购正在崩溃的供应商（例如，甲骨文收购Sun以保留Java），它可以在一定程度上控制这种情况，但这通常是一个成本高昂到令人望而却步的选择。同样，健康的 codebase 和熟练的开发人员能够带来更高的适应能力，公司可以利用这些能力来替换不再维护的子组件或将软件移植到新平台。

友好邻居崩溃的一个特殊情况是主要客户的崩溃。如果公司未能充分分散其客户群，就可能发生这种情况。这通常是“摇钱树”综合症的结果，即软件公司为了一个“战略”客户而优化其产品，却以损害产品竞争力及其适应其他客户的能力为代价。如果代码库未能保持模块化状态，将客户特定功能实现为可插拔行为，那么主要客户的流失可能成为致命的打击。

无法改变

“能够存活下来的，不是最强壮的物种，也不是最聪明的物种，而是最能适应变化的物种。”
—— 莱昂·C·梅格森

有时，一个社会（或一家软件公司）即使具备抵抗即将到来的崩溃的内在能力，也可能因各种社会原因而未能适应，我将对此进行描述。

未能预见威胁

“群体可能会做出灾难性的事情，因为他们在问题出现之前未能预见到它[因为]他们以前从未遇到过此类问题，因此可能没有意识到这种可能性。”自软件产业诞生以来，其发展呈指数级增长，导致其持续不成熟和集体失忆，因为大多数从业者在行业中的时间不够长，无法经历过去的失败并从中吸取教训。这导致对技术新颖性（年轻人特有的）的过度关注，却忽视了技术历史，未能从过去的成功和错误中学习。

这种现象有两个方面。从技术角度来看，它主要由软件架构师（指角色而非职位）未能发现代码、架构和文档腐烂以及即将到来的技术转变所致。这具有悲剧性的讽刺意味，因为架构师的工作就是通过准备现有产品来优雅地处理问题，从而预测并避免未来的问题。从管理角度来看，如果高级管理人员本身没有技术教育背景，他们就无法预见低技术质量的危险后果。此外，未能理解软件开发到底是什么可能会导致应用对其他行业分支有意义但对软件开发失败的功能失调的组织模式。

未能察觉威胁

“在一个社会预见或未预见到问题到来之后，它可能未能察觉已实际出现的问题。造成这种失败至少有三个原因，它们在商界和学术界都很常见。”

“首先，一些问题的根源是字面上难以察觉的。”普遍使用的SCRUM方法可能会欺骗管理者和开发者。当产品年轻且规模小的时候，每个 Sprint 通常都会成功，因为即使是糟糕的战略和战术决策，由于代码的“体量”仍然很小，其“摩擦力”也很低。随着时间的推移，产品不断成长，当选择简单、低风险的功能进行实现时（无论是有意还是无意，但通常是基于成本而不是价值），Sprint 仍然可能成功。这种情况可能持续存在而不被发现，直到需要某种产品方向的转变。当这种情况发生时，一系列成功的 Sprint 会迅速变成一个焦油坑（参见图5）。

“问题发生后未能察觉到的另一个常见原因是远距离管理者，这是任何大型社会或企业中潜在的问题。”这个问题有三个常见方面。首先是开发团队与管理者和/或架构师之间的地理距离。在这种情况下，远距离管理者（或架构师）获取关于产品当前状态的准确信息以实施适当纠正措施的能力有限。这通常发生在开发外包的情况下，特别是如果地点之间时差很大（讽刺的是，正是由于这个原因，印度是北美公司最糟糕的外包地点）。其次，多层组织倾向于在中层管理层形成一个真相温跃层。在这种情况下，关于事态的真实信息被压制，并随着管理结构向上冒泡而被成功的积极幻想所取代。这使得高层管理人员与“现场”疏远，即使他们实际占据相同的物理位置。第三，非技术经理和不编写代码的软件架构师（原文如此！），舒适地躲在他们的象牙塔中，可能对腐烂的代码库一无所知，因为他们根本不关注它。在这种情况下，代码库就是“现场”，而经理（或架构师）与它疏远。“由于远距离管理者造成的失败的对立面是由于现场管理者造成的成功。”《21世纪手术团队》是一种利用现场管理来解决问题的方案。

“也许社会未能察觉问题的最常见情况是，当问题以缓慢的趋势出现，被广泛的起伏波动所掩盖时。”当干旱与降雨交替出现时，可能很难发现即将到来的气候变化。土壤一点一点地侵蚀，源代码一行一行地侵蚀，市场份额百分之一百分之一地减少。很难发现潜滋暗长的技术债务。对于新手（甚至是资深）开发人员来说，这可能由所谓的渐进常态化引起，因为他们可能从未真正接触过精心设计的解决方案，并认为事情就应该是这样。另一方面，如果市场需求缓慢变化，管理层可能无法识别正在崛起的竞争对手、失败的合作伙伴或市场需求的变化，直到达到某个临界点（然后事情开始以惊人的速度变化）。

未能采取行动

“失败路线图上的第三站是最常见、最令人惊讶的，需要最长的讨论，因为它采取了多种形式。与[所有人]预期的相反，事实证明，社会即使在问题被察觉后，也常常未能尝试解决问题。”大公司由于沟通路径的复杂性而反应迟钝。此外，它们倾向于随着时间的推移积累保守和有意识的人，这些人擅长在稳定环境中进行优化。当环境发生变化时，这两个因素结合起来导致它们即使周围每个人都清楚地知道方向错误，也仍然会朝着错误的方向前进。

“理性行为”

“许多此类失败的原因属于经济学家和其他社会科学家所称的‘理性行为’范畴，源于人与人之间利益冲突。也就是说，有些人可能会正确地推断，通过从事对他人有害的行为，可以促进自己的利益。科学家称此类行为为理性，正是因为它采用了正确的推理，尽管它可能在道德上应受谴责。”

“理性行为”最常见的表现之一是短期思维，人们专注于向其上级展示的积极形象，并借由一系列短期即时成功来实现。这种方法不仅“理性”，而且从犯罪者的角度来看确实是理性的。软件开发固有的无形性使得难以正确评估一个人的贡献，因此“熟练度形象”往往是一个人职位和薪水唯一的基础。这种行为贯穿整个组织，从开发者（Sprint vs 产品）、中层管理（项目 vs 产品）到高层管理（季度报告 vs 可持续业务）。《21世纪手术团队》是旨在至少在开发层面减轻这种现象的解决方案。

这种现象的另一个表现是流氓程序员的增殖，他们故意不愿意采取行动（“不关我的事”的态度）。这通常是由公司深层道德和经济价值观的腐烂所导致，这些价值观助长了社会懈怠。“手术团队”方法通过施加所有权和透明度来对抗这种现象，但无法解决更深层的问题。

“理性思维”的另一个表现是缺乏客户管理。如果主要客户对维持软件公司生存没有长期利益，那么他们“理性”地从公司中榨取最大价值，然后抛弃其尸体。如果软件公司无法管理客户需求，其产品的代码库和架构完整性将最终因相互矛盾的客户需求而支离破碎。

非理性行为

“与所谓的理性行为相反，未能尝试解决已察觉问题还包括社会科学家所认为的‘非理性行为’：即对每个人都有害的行为。这种非理性行为通常发生在当我们每个人个体被价值冲突撕裂时：我们可能因为某种我们坚持的根深蒂固的价值观而忽视一个糟糕的现状。”

我个人在软件公司观察到的最强烈的非理性行为是沉没成本谬误。大多数时候，软件公司顽固地坚持修补和“重用”其现有软件（或软件组件），仅仅因为他们过去投入了太多，即使开发新软件或更常见的是用现成解决方案替代会更有意义。在当今开源软件“免费如啤酒”的丰富性下，这尤其不理性。

第二种最非理性的行为是，在开发成本飙升、增长选择耗尽或竞争加剧的情况下，未能“自相残杀”公司当前的“现金牛”产品（尽管有些公司成功地做到了这一点）。这与沉没成本谬误一样，深深植根于人类普遍存在的损失厌恶现象。

相比之下，整个公司最明显的非理性行为是拒绝改变，固守不再有意义的价值观。格陵兰北欧人在小冰河时代到来之际，选择了坚守欧洲生活方式，最终灭绝，而不是采纳因纽特人的生活方式并生存下来。同样，一些软件公司面对“气候变化”可能仍然试图像这种变化无关紧要一样运作（“我们是桌面软件公司，不是网站”，“我们是产品公司，不是服务公司”，“我们是硬件公司，不是软件公司”）。此外，他们经常努力通过采用各种“效率提升措施”来推动其当前活动，这只会让他们更快地朝着错误的方向走向最终的崩溃。

未能修复

“最后，即使一个社会已经预见、察觉或试图解决问题，它仍然可能因显而易见的可能原因而失败。问题可能超出了我们目前的能力范围，解决方案可能存在但成本过高，或者我们的努力太少且太迟。有些尝试的解决方案适得其反，使问题变得更糟。”

当公司面临如前所述的代码库侵蚀导致的开发者流失时，它就变得脑死亡。随着所有最优秀的开发者离去，剩下的人群可能没有足够的认知能力（或者仅仅是动力）来正确实施所需的纠正修复，因此重写的代码可能最终会像原始代码一样复杂，并最终被废弃。即使代码库腐烂不会导致开发者腐烂（我怀疑这不太可能），修复或重写的成本也不遵循线性函数，而是指数函数，平均指数值约为1.5（参见布鲁克斯）。为了证明这一点，让我们做一个思想实验。如果我们有一个100行代码的程序，并且每行代码都独立于任何其他行（可能性很小），那么改变一行代码就不需要任何其他改变。因此，改变10行代码所需的时间将是改变一行代码所需时间的10倍。这意味着工作量将遵循代码行数的线性函数。另一方面，如果程序的每一行都依赖于其他所有行（同样可能性很小），那么改变一行代码也将需要改变所有其他行代码。在这种情况下，改变10行代码将需要改变其他所有行10次，这将得到100/10*100 = 1002/10，这是一个指数函数。真实程序在这些极端之间表现出相互依赖性（这就是为什么通常假设指数为1.5），但复杂的设计、草率的编程和黑客行为会使这个指标，并最终使成本，更接近二次函数。此外，开发者的无能可以使指数进一步提高，几乎没有限制（如下所示）。

这也是为什么雄心勃勃的重写往往会导致成本爆炸、功能放弃、性能问题并最终失去市场的原因（参见网景）。

未能修复的另一个原因可能是管理层对软件开发过程的误解或完全缺乏理解（因无知而脑死亡）。这发生在（惊人地普遍存在的）按照“例行公事”模式运营的公司中，这种模式被杰拉尔德·M·温伯格描述为过度关注流程，培养“超级英雄经理”的神话，并总是寻找银弹。这些组织对每一次危机都通过调整组织结构和流程来应对，希望这些能奇迹般地解决技术问题。同时，他们积极阻止开发人员处理这些问题，不愿提供所需的时间和资源。

超越戴蒙德框架

尽管戴蒙德的书中没有明确指出，但有些社会之所以失败，是因为它们建立在本质上不可持续的地区，那里恶劣的环境条件被一些宝贵的自然资源所抵消，这些资源可以用来交换食物、建筑材料、工具等商品。美国的鬼城曾经因金矿开采而繁荣，或现代石油富裕的沙特阿拉伯都直接印证了这一点。对于软件公司来说，当它们建立的商业模式从长远来看不可持续时，就会出现这种情况。其中一种模式（实际上在过去几十年中因各种原因运行良好）是基于销售功能（或整个版本）的模式。这种模式的问题在于它受边际效用递减规律的支配（即从功能中获得的收入随着时间的推移而减少，就像石油或黄金最终会枯竭一样）。例如，以文字处理器应用程序为例。能够以所见即所得的方式编辑段落对客户来说是一个核心功能，具有巨大价值，并刺激销售，但能够为每页添加水印对于大多数现有用户来说价值不足以考虑升级成本。相反，订阅模式似乎更具可持续性。在这种模式下，客户每次运行软件都会获得价值，因此定期与软件开发者分享部分价值似乎是公平的。这样做的一个额外好处是，软件开发者不必为了销售而被迫推出新功能，并且可以在仍然盈利的情况下改善产品的非可见质量。

戴蒙德没有提及，但人类已知的其他社会崩溃原因包括自然灾害，其中可能最好的例子是古庞贝。软件公司似乎不容易受到洪水、地震或火灾等自然灾害的影响，这得益于异地备份（如果系统性进行）和疏散程序，以及对计算机等物理资产（易于更换）或建筑物（远程工作）的极低依赖性。

最后浮现在脑海中的社会崩溃原因是纯粹的政治原因。正如社会可能受到恶意独裁者的统治，给其公民带来灭亡（如柬埔寨共产党），软件公司也可能成为盲目、敌对和自私自利的高层管理人员的牺牲品，导致其衰落。然而，我怀疑与迄今为止提到的所有因素相比，这种情况极为罕见。

结论

考虑到以上所有因素，我认为崩溃是任何盲目追求无条件增长和无条件利润的软件公司的自然且不可避免的最终结局。社会和公司都需要积极主动、系统性地采取行动来防止崩溃（就像蒂科皮亚岛的人们几个世纪以来通过 регулирова农业、渔业和人口那样）。

与社会相比，软件公司的问题在于事情出错的速度要快几个数量级。一家精益创业公司热情地遵循松散的 SCRUM，通过每个 Sprint 添加大量功能快速构建初始产品。它在积累技术债务的同时获得了市场份额，然后突然撞墙。为了应对这种情况，它增加了更多人手，任何概念系统的一致性都随之瓦解，因为人多反而坏事。成本飙升，敏捷性丧失，最终公司破产（所有这些都发生在几年之内，而不是几十年）。图7通过展示所讨论现象的相互影响总结了这一过程。

图7：崩溃因素的相互依赖性（颜色无关紧要）。每个箭头指向积极影响（放大）的方向。每当箭头是双向的或在图中形成一个环时，就会形成一个正反馈循环，公司以指数级的速度变得不稳定，最终可能导致崩溃。

为了从所有阴郁的故事中吸取教训，贾雷德·戴蒙德还分析了一些实际上成功长期生存和维持的社会。这使他确定了区分过去幸存社会和失败社会的两个关键选择：“在问题已可察觉但尚未达到危机程度时，敢于进行长远思考并做出大胆、勇敢、前瞻性的决策”，以及“敢于做出关于价值观的痛苦决策”；决定“在新的变化环境下，哪些曾对社会有益的价值观可以继续保持”，以及“哪些这些珍贵的价值观必须被放弃并替换为不同的方法”。我倾向于认为这也适用于软件公司。

历史

• 2021年1月5日：初始版本