编者按：您也许听说过「软件正吞噬世界」，但本文提出了一套能更具体解释「软件如何吞噬世界」的经济学思考框架，很有意思。
软件开发者对我们的工具以及工具的难用程度大肆抱怨是一种流行的态度。也许我是一个乐观的人，因为我的观点完全相反！我的第一份工作是在 1999 年的软件工程师，在过去的二十年里，我看到软件工程的变化使我们的生产力提高了几个数量级。下面先列举一些我工作上参与过或相关联的例子：
Spotify 用 C++ 构建了一个完整的 P2P 架构，以便将流媒体音乐分发给听众，这在今天是一个微不足道的问题——大家只需将数据放在 CDN 上就行。
我曾经编写自定义 MapReduce 自动脚本来提取基本统计信息，然后等待数小时以完成这些任务。今天，这些将是在几秒钟内即运行完成的数据仓库中的 SQL 查询。
我曾经经营过一家网店，花了一周时间实施信用卡支付。今天，使用 Stripe 支付集成只需 15 分钟。
更不用说开发团队流程的变化了：
单元测试在业界非常罕见——我第一次遇到它是在 2006 年在 Google 工作。
当 git 是算新工具时，git-flow 是流行的工作流程，与我一起工作的许多开发人员花费过多时间（例如，20-30%）的代码工作，在 git 里只是 rebase 就能实现。
CI 系统很脆弱，CD 基本上不存在，部署是可怕的手工劳动。
这些只是例子——我可以继续列举一整天。就像关于软件生产力的经典 No Silver Bullet 论文一样，这些东西本身都不是显著的改进。但是生产力的提高是累积而来的，而且是指数规模的累积，这意味着：当你的时间尺度是几十年时，我们看到指数级的改进并不是不合理的。
（注：我将在这篇文章中使用术语「工具」来指代各种软件行业的工具和对象：框架、库、开发过程、基础设施。）
围绕软件，世界的一个极其粗略的分类是：
有些事情有很棒的软件
有些事情有平庸的软件
有些事情没有软件
到目前为止，这很明显，所以我会继续说下去：如果有能力以零成本瞬间生产无限量的软件，那么最后两个桶就会消失。平庸的软件之所以存在，是因为有人无法聘请更好的工程师，或者他们没有时间，或者其它原因。没有软件的事情……什么都有？我的意思是，为什么你的鞋子没有内置步数追踪器？为什么 Mark in Accounting 仍会生成 PDF 发票并将其通过电子邮件发送给客户？为什么不……我可以继续说下去。
我们显然已经朝着这个方向前进了很长时间。我的观点是，还有很多事情可以使用软件。为什么还没有发生？因为有人做出了构建该软件的成本太高的经济决策。雇用工程师并培训他们并完成工作需要花费金钱和时间。那么我们如何看待这个成本呢？
让我们回到我关于软件工程师生产力随着时间的推移而提高的观点。用经济学术语来说，这意味着每次产出的价值上升。在需求方面，这意味着构建软件的成本下降。以前需要 1,000 小时，现在需要 100 小时。
如果需求是固定的，这将意味着大量失业和工程师的低薪水，但需求不是固定的！正如我之前所暗示的，构建软件的成本降低意味着开辟了新的机会。以前花费 1,000 小时的工程努力来构建您的 Gizmo 是不值得的，但很可能值得 100 小时。有巨大的潜在需求。您甚至可以为工程师支付更多的每小时费用。
这些事情都可能同时发生：
开发了更多软件
软件工程师工资上涨
软件工程师的数量增长
这可能违反直觉，因此值得将其与需求固定的情况进行对比。假设发明了某种工艺，使尿布工厂的产量增加了 10%（保持所有成本不变），并且所有尿布制造商都可以立即使用该发明。结果是什么？市场上将出现暂时的尿布过剩，市场将趋于新的平衡，供应收缩以满足需求。在此过程中，一些工厂将关闭，纸尿裤价格将下降。
与软件工程师的不同之处在于，当成本下降时，需求就会增长。你阿姨的牙科诊所过去没有网站，但现在值得拥有一个完整的在线预约系统。您的孩子去的学校突然有一个应用程序可以向父母发送通知。我不知道——我的意思是，随着价格下跌，更多的需求会出现。
这种情况不仅发生在整个经济中，也可能发生在微观范围内。如果您有一个数据科学家团队，并且您引入了一种工具，可以使生产力提高 2 倍？太棒了——你只是将每次增量招聘的投资回报率翻了一番，而且你应该去雇用更多的人。我从未见过一家公司的数据科学家会失业：总是有更多的事情需要分析。
这会永远持续下去吗？我想在某种最终状态下，我们会遇到一个看起来像奇点的东西，软件本身构建软件的速度如此之快，以至于需求无法随着供应而增长。这正是我担心软件工程师失业的时候。但在接下来的几十年里，我认为我们将看到软件工程师的数量不断增长，这是一个相当不错的预言。
软件作为一个领域的增长和薪水的增长本身显然吸引了更多的人进入这个领域，但我认为还有另一件事正在发生。
几十年前，软件工程很困难，因为您必须从头开始构建所有组件并解决所有这些基本问题。您需要存储来构建服务 100 万并发用户的东西吗？浏览有关一致性哈希、CAP 定理、CRDT 等等的论文，卷起袖子，为 100,000 行硬核 C++ 做好准备。
今天，这些问题「大部分」都得到了解决，你可以使用现成的工具来解决大部分问题。不过也不容易！就像我之前提到的，没有灵丹妙药，外面有一百万种工具，您需要根据最佳实践了解如何将它们拼接在一起。但我们知道，这又是一种不同类型的困难。
几十年前，软件工程偏爱那些具有深刻抽象思想的人——他们可以将复杂的软件从原子中拼接起来。对我来说，今天它看起来更像是一门手艺——更多的是关于学习应该使用什么工具来完成什么工作。我的意思是，它仍然非常有利于深度抽象的思想家，但相对而言，这种技能是一个比过去更小的差异化因素。
我认为这改变了软件工程师供需等式的供给侧。今天成为软件工程师的障碍已经不同，它开辟了更多的人才库。这释放了新的供应来源，这意味着更多的软件将被创造出来。
构建软件曾经是（现在仍然是）公司的一项非常昂贵的工作。在一般公司，您仍然有看似无穷无尽的积压工作。企业「工厂」的软件方面仍然经常是公司的瓶颈。
当您的小部件制造商成为制造工厂的瓶颈时，您会怎么做？您确保瓶颈在任何时候都以满负荷的方式运行。这意味着您集中了小部件制造商的资源管理——您对输入进行控制，并投入大量精力来确保按什么顺序制作什么小部件。
大多数公司的运作方式仍然大致如此。但是，（在我看来）拥有异常高效的工程团队的公司正在以稍微不同的方式组织工作。他们倾向于分散优先级，并在紧密的迭代中直接与产品和业务利益相关者合作。当资源不再是瓶颈时，您可以通过将资源分配给许多不同的团队来实现更高的迭代速度。我并不是说要清楚地下放管理权。我的意思是将积压工作分散到直接处理业务需求的小团队中。
在此模型中，您没有营销团队将某些东西放在工程团队的待办事项上。你有一个跨职能团队负责收购，其中有些人是传统营销人员，有些人是工程师。你可以想象这几乎涵盖了典型公司的所有职能：客户支持、财务或其它任何职能。
我觉得超级迷人的一个平行历史（案例）是：为什么电力需要这么长时间才能改变制造业。蒸汽机时代的工厂是围绕全能蒸汽机的配电而建立的。能源是宝贵的资源，因此很自然地认为制造工厂是围绕能源分配而建造的。电力改变了这一点，并分散了能源生产，但制造工厂需要很长时间才能重新调整并利用这一点。
（注 1：这不是一个完美的类比，因为蒸汽动力不仅是宝贵的资源，也很难制造小型蒸汽机。）
（注 2：我链接到的文章的主要观点是，创新往往需要时间来释放生产力，因为第一次尝试使用新技术往往试图将其改造成遗留结构。例如：互联网首先创建 DVD-by - 邮件，但真正的互联网原生创新是流媒体视频。）
我一直在谈论使工程师更有效率的工具，但这并不是故事的全部。显然，非技术人员也使用许多工具来完成自己的事情，这很棒！但我也看到大量的工具是这样开发的，使得人们不必与工程师一起协同工作。为什么？几个原因：
迭代速度：向工程师解释您需要什么的成本使其不值得这样做
工程资源不可用（或太贵，或其它）
您只需要一小部分工程师，但该市场不存在
构建某些东西需要一些特殊的领域知识
工程师很奇怪，闻起来很有趣
好吧，最后一点只是一个愚蠢的笑话。我认为这几点要点涵盖了大部分原因 。
其中，我认为第一个（迭代速度）是 100% 有效的理由。例如，我鼓励所有业务人员学习 SQL，这样他们就可以自己运行查询。
我认为不幸的是第二个（没有可用的工程资源）。我们中的很多人可能都遇到过手动操作的数据处理（管道），人们使用宏发送 Excel 文件，每天早上将新数据复制粘贴到电子表格中，或类似的事情。这有时被称为「影子技术」。如果有专门的工程师资源，建造和拥有这些东西的总成本可能会低得多。
但是，非工程师正在构建技术的事实证明了对工程师的需求。在许多公司，工程师无法满足需求。因此，通过更好的工具，随着时间的推移，可以满足更多的需求。处于工程师生产力前沿的公司可能会较少看到这些问题：工程师将尽早参与并解决业务问题。
第三点（部分资源）可能适用于小公司。如果您是牙医，您不会聘请工程师为您构建服务预约软件。幸运的是，他们受益于全行业产出的增加：可能会有一个全新的牙医软件生态系统可供购买（因为构建它会变得更便宜）。
最后一点（特殊知识）有一定的道理。我经常看到业务人员，作为让基本原型运行的第一线攻关小团队，构建手动工作流程，这些工作流程后来被工程师接管并自动化。与之相对的是，随着权力下放的增加，工程师将越来越多地发展领域经验。例如，许多公司都为人力资源和财务团队提供了专门的数据科学和数据工程师资源。
所有这一切的一个有趣的推论是：它创造了一个积极的反馈，一些公司将进一步落后：
缺乏采用新工具意味着落后于利用这些工具的公司。
软件工程师的更高薪水意味着这些公司的定价超出了高端招聘市场。
未能重新调整工厂意味着较低的迭代速度。
缺乏工程师意味着在不使用工程师的情况下采用工具来构建技术的诱惑，相关成本要高得多。
与此相反，处于最前沿的公司将看到他们的软件工程师生产力激增并且迭代速度提高。
我在抵押贷款行业工作了六年，我已经清楚地看到这些趋势在我面前表现得非常清楚。最大的落后者正在拼命采用 RPA 和临时拼凑的数据处理工具，将现成的 POS 和 CRM 软件结合在一起。稍微好一点的公司都有自己的工程团队，但似乎未能将加工厂重新调整为技术驱动的公司。我的公司 Better 暗中投资我在这篇文章中提到的所有内容，也许还有其它一些趋势。
对于我认为可以简明扼要地放入因果图中的东西来说，这是很多话：
软件工程师生产力 vs. 软件供需平衡
这图显然不是关于软件世界所发生的一切的完整理论。还有许多其它趋势，例如「互联网削弱物理护城河效应」，以及创造更多规模经济的软件产品。但我想，这图解释清楚了很多生产力和软件供需平衡关系的疑问。
如果没有产生预测或政策建议的能力，理论是无用的，所以我敢打赌：
现在是成为软件工程师的好时机
软件工程师工具市场将继续增长
许多「传统」公司将落后于生产力的提高
新入行者将威胁这些公司并在很大程度上取得成功
每家公司都应该考虑如何重新调整他们构建（软件工具）技术的方式，以专注于去中心化和更高的迭代速度，将工程师嵌入整个企业或「工厂」
从长远来看，公司采用某类工具的唯一目的如果是在没有工程师的情况下构建技术，这并不是一个好主意
软件工程师应该全心全意地采用使他们更有生产力的工具：工具使他们更有价值
拥有高生产力工程团队的公司将拥有更快增长的工程团队（因为雇佣更多工程师的投资回报率更高）
这篇博文是我脑海中一些以前不相关的想法的汇总。有些对读者来说可能非常明显，有些则不那么明显，希望您能从后者了解到有用的东西。
加载中,请稍侯......