软件设计方程

今天，我在思考一个小方程，它可能实际上解释了软件设计的几乎所有原则。虽然我不知道它是否能在数值上进行数学求解，但它确实展示了软件开发决策中存在的因素以及它们之间的相互关系。

在深入探讨这个方程之前，我必须定义设计师在决定是否实现某个功能或如何实现时存在的因素：

• 实现潜在价值（简称Vi）：实现这个功能有多“有价值”？例如，如果我们向程序中添加一些可以直接防止某人死亡的功能，那将非常有价值。如果它只是可能防止未来单个错误消息中的拼写错误，那几乎毫无价值。这种“价值”可以是针对最终用户或其他程序员的。当我们谈论仅影响代码而不影响最终用户的设计决策时，灵活性是主要价值之一——这种灵活性有多重要？潜在价值与您需要它的情境发生的可能性是分开的。这是下一个问题。

• 价值概率（简称Pv）：这个价值实际上被最终用户（对于功能或功能变更）或另一个开发者（对于某些设计决策）实现的几率是多少？如果我们添加代码灵活性以允许与外星猿类潜在接触，那不是一个非常可能发生的事件。如果我们添加一个对每个用户都立即有用的功能，那就是100%的概率。（一个功能对多少用户有用也是价值概率的一部分。）

• 实现成本（简称Ei）：实现这个功能有多难？这是一个一次性成本——首次创建这个功能所需工作的即时难度。这可能会以人时来衡量。

• 维护成本（简称Em）：未来维护这个功能需要多少努力？（这包括通过实现这个功能而添加到维护整个程序的任何努力。）这会复杂化整个系统的维护吗？这是一个随时间增加的量。与实现成本类似，这很可能会以人时来衡量。

我们试图确定的是实现合意性（简称D）。这回答了“这是我们该做的事情吗？”和“实现这个的优先级应该是什么？”的问题。

方程的最简单形式是：

D = (Pv * Vi) / (Ei + Em)

或者，用英语来说：实现合意性与价值概率和实现潜在价值成正比，与总成本（包括实现成本加上维护成本）成反比。

然而，这个简单形式的方程缺少一个关键因素：时间。我们实际上想知道的是当时间趋近于无穷大时这个方程的极限，这给出了真正的实现合意性。所以让我们从逻辑的角度来看待这个问题：

• 实现成本是一次性成本，永远不会改变，因此基本上不受时间影响。
• 实现价值可能随时间增加或减少，取决于功能。这是不可预测的，因此为了这个方程的目的，我们可以假设它是一个不随时间变化的静态值（尽管如果在您的情况下不是这样，也请记住这个因素）。人们甚至可以认为维护成本实际上是“维持这个确切价值水平所需的努力”，因此价值确实会随时间保持完全固定。
• 价值概率作为一个概率，当时间趋近于无穷大时趋近于1（100%）。
• 维护成本基于时间，当时间趋近于无穷大时趋近于无穷大。

乍一看，这听起来好像设计是无望的，因为维护变成了无限的努力——一个没有任何潜在价值可以超越的量——而且似乎必须考虑每一种可能性，因为给定无限时间，概率似乎表明每一种可能性都会发生。然而，这些陈述并不真实，因为您必须考虑这两个项目增加的速度。如果基本维护成本非常小，那么即使时间推移，它也会保持很小。您可以说任何设计决策或功能都有一个“维护系数”，它决定了维护成本随时间积累的速度。就价值概率而言，如果它是一个非常小的数字，它可能保持很小直到数千年或数百万年过去——因此如果维护成本以高速率增加，那么它将轻易超过价值概率，并且实现合意性将随着时间趋近于无穷大而趋近于零。

这个方程实际上告诉我们的是，在时间方面，最重要的平衡因素是价值概率与维护成本。如果价值概率高而维护成本低，那么合意性仅取决于实现潜在价值与实现成本——产品经理可以轻松做出的决定。如果价值概率低而维护成本高，实现的唯一理由将是近乎无限的实现潜在价值。

这有趣地表明了为什么编程语言和开发框架的小改进会导致最终产品的巨大变化——因为维护成本的微小降低可以对实现合意性产生巨大变化。否则会被产品经理视为不可能而丢弃的功能成为基本设计计划的一部分。抛光UI变得更有吸引力，因为它需要更少的实现和维护努力。

最后，我认为这最准确和真实地传达了为什么简洁性如此重要——因为简洁性决定了上面我谈到的“维护系数”。维护简单代码所涉及的努力随时间增加非常缓慢——有时如此缓慢，以至于在您的一生中永远不必投入任何维护努力。

关于这个方程，还有很多可以说的。您对此有什么想法？有人对如何数值计算实现价值，或者它是否可以分解为一组其他可数值计算的因素有任何想法吗？关于它，您有任何要说的，我都很感兴趣。

-Max

评论

Havvy 说：2010年1月6日下午3:39 您的方程中有一个百分比和一个非百分比。如果您使它们都成为非百分比，维护似乎就不那么令人生畏了。应该查看该函数对时间的导数来回答这样的问题。当然，要做到这一点，您必须正式将时间添加到方程中。

回复

Max Kanat-Alexander 说：2010年1月6日下午3:45 我不确定我完全理解您关于百分比的点。概率根据定义是一个百分比。 如果我们说 Em = C * t1，其中 C 是维护系数，t1 是时间，那么我们关心的是维护系数，尽管它本身可能是其他东西的导数。 -Max

Max Kanat-Alexander 说：2010年1月6日下午3:47 更多作为给自己的笔记，可能 C 的最佳单位是“人时每小时”，其中 1 意味着“这个功能被连续工作 24 小时，永远持续。”

回复

Mark Castillo 说：2010年1月6日下午4:40 时间 T 在哪里？ 哦，糟糕……我应该进一步阅读……您提到了。哈哈…… “然而，这个简单形式的方程缺少一个关键因素：时间”

回复

johnjbarton 说：2010年1月6日下午8:48 这个方程还告诉我们“永远不要维护软件”。既然您无法控制 Pv，您应该使 Em 为零，并在不同的产品中持续投资 Ei，直到找到大的 Vi。然后将您的初创公司卖给某个处理 Em 的傻瓜，而您在沙滩上喝玛格丽塔酒。哦，等等，它告诉我们更多：您应该支付很多其他人‘Ei’，然后将 Vi 赢家卖给傻瓜。然后您就是风投。

回复

Max Kanat-Alexander 说：2010年1月7日上午7:19 哈哈！！我喜欢它。（对于任何过于字面理解的人——Em 当然是维护成本，无论您是否维护它；它只是变更将需要的固有维护努力。） -Max

回复

Tony Mechelynck 说：2010年1月7日上午10:41 您的方程中有一些模糊定义的术语，也许应该如此，因为定义将取决于视角的距离和广度。让我解释。例如，什么是“一个产品”？在最远和最广的视角中，Netscape pre-4、6-7 和 8-9、Mozilla Suite、Firefox、Thunderbird、SeaMonkey 等，都构成“一个产品”。当我们更近地看并更详细地看时，Netscape pre-4 是一个产品，Netscape 6+ 是一个或两个，Firefox 是一个，Thunderbird 是一个，Mozilla Suite 与 SeaMonkey 一起是一个、两个或三个（我不确定，如果是两个，边界应该放在 Sm 1.x 之前还是之后？），等等。从更近的角度看，每个主要版本（Fx1、Fx1.5、Fx2、Fx3.0 等）本身都是“一个产品”。 我相信这些观点中的每一个都是合法的，并且您的方程可以有效地应用于每一个（当然，有适当的系数选择）；但当从一个视角转到下一个时，每个“子产品”的部分或全部 Ei 除了第一个之外，都被吸收到更大整体的 Em 中，或者在放大时反之亦然。 现在问题出现了：Netscape 是否应该通过什么都不做来做得更好？到目前为止，已经投入了真正巨大的人力和其他资源到我之前提到的更大“产品”中。该投资是否“回报”将取决于如何衡量 Vi，考虑到，是的，美元，还有选择自由、可定制性等。此外，Vi 应该衡量为投资了劳动和/或金钱的人们和法律实体的“投资回报”，还是作为全球的总收益？

回复

Max Kanat-Alexander 说：2010年1月7日上午11:34 这些都是非常好的问题。 我会说，最终，人们可以衡量全世界的 Em 和 Ei——人们可能做出严重糟糕的 API 选择，这会严重增加您库用户的 Em，这可能是需要考虑的事情。通常，尽管，“单个项目”是明确定义的，并且我个人必须做出的大多数决策很容易通过限制自己手头的因素来判断，我使用自己的判断为每个单独决策单独确定。 衡量 Vi 的方法目前确实未确定。我认为这在某种程度上取决于设计师及其目标。我认为金钱是一种完全有效的方式来衡量某些情况下的某些事情（事实上，如果您愿意，您可以用金钱衡量 Vi、Em 和 Ei，并得出一个数值可解的方程，尽管它可能不是足够广泛的 Vi 衡量，并且确定 Vi 的货币价值本身将是一整本书），但全球的总收益是我作为开源开发者更经常考虑的事情，我认为，比我重视投资回报率更多。 -Max

Max Kanat-Alexander 说：2010年1月7日上午11:35 我会说，最终，人们可以衡量全世界的 Em 和 Ei——人们可能做出严重糟糕的 API 选择，这会严重增加您库用户的 Em，这可能是需要考虑的事情。 尽管思考这一点，如果您是一个库，Vi 可能是“减少其他项目的 Em”，因此您甚至不必太复杂化。 -Max

回复

Alex Vincent 说：2010年1月8日上午12:26 您称之为简单的英语吗？我必须承认我解析那个句子有些小麻烦。我想我更好地理解方程了。:-p

回复

Max Kanat-Alexander 说：2010年1月8日上午9:25 哈哈哈，这是一个足够公平的陈述。我从前面的句子中删除了“简单”一词。

回复

Janson 说：2010年1月11日上午8:52 它假设编程是一门科学。我认为应该是艺术。它要么美丽，要么不美丽。考虑到通常进入编程的热门人才，如果您给他们任何超越指南的东西，那将是侮辱。这个方程无论如何在数学上不严谨，tjohnjbarton 建议 您喜欢这个“编程美学的一般原则——一个读者解释方程”吗？

回复

Max Kanat-Alexander 说：2010年1月11日下午1:23 嘿 Janson。编程是一门科学。任何科学的应用都是一门艺术，但仅仅因为有人没有正确发展编程科学并不意味着这样的科学不能或不应该存在。就像建造一座桥——背后的数据是科学的，但工程师如何选择应用科学是一门优雅匹配约束等的艺术。 您知道，我认为您实际上可以对方程进行数学严谨的证明。我没有研究过，但我认为这是可能的。 -Max

回复

Janson 说：2010年1月12日上午1:43 嗯。 嗯，我编程过，主要是为了我的系统模拟课程，并且做了足够多的工作来运行它而没有错误，但也花了很多时间。所有时间，我都在画流程图，并试图给我的“流动”想法赋予形状。 而那些在 half 我的时间内完成的人只是去了 Rambo。他们不断敲击键盘并完成了。我 tempted 要说关于 10000 头驴和莎士比亚作品的谚语，但我意识到我是那个 typing 了 10000 年的人。 我讲述这个轶事是因为所有完成它的人都吹嘘他们如何通过“直觉”、艺术地等完成它。您知道大学生如何吹嘘。但然后，大学编程一点也不像主要的软件开发活动。 嗯，我不再定期编程了，但指挥一个卑贱的机器奴隶的魅力仍然吸引着我。我浏览了您之前的帖子，您似乎说的正是我过去相信的反面。但嘿，您是真正的热门人物。

回复

Max’ Lesestoff zum Wochenende | PHP hates me - Der PHP Blog 说：2010年5月14日下午8:58 […] HTML5 很好的摘要关于如何确定浏览器的某些功能（HTML5） 代码简洁性 » 软件设计方程 今天我在思考一个小方程，它可能实际上解释了软件设计的几乎所有原则。 […]

回复

Nick Barnes 说：2010年12月13日上午7:18 您需要计入折扣率：今天 100 万美元在 2100 年的成本要少得多，少得多。

回复

Max Kanat-Alexander 说：2010年12月13日上午11:37 嗯，是的，通货膨胀发生，但我们主要谈论的是努力，而通货膨胀背后的一般想法是，投入生产的努力量总是得到 adequate 补偿。所以，无论现在一个月的程序员时间成本是多少，它在 2100 年将花费“相同”，即使那个“相同”量是更大的美元数字。所以最终，那个因素在功能开发合意性的考虑中是无关的。 -Max

回复

cazare bran 说：2011年1月13日上午7:15 维护成本……您应该总是维护它（在我看来）

回复

Jenny 说：2011年1月15日上午5:18 IMHO，通货膨胀只发生在供应链的原始来源受到影响时。其次，像 Max 说的，某些 xyz 量的“价值”将总是与几十年甚至几百年后的“价值”直接成正比。那是因为努力是相同的！ 和平，Jenny

回复

Locusto 说：2011年4月15日下午2:30 我想我正处于一个项目的中间，我可以测试您方程的有效性。得检查我的老板会说什么。

回复

Max Kanat-Alexander 说：2011年4月15日下午5:30 酷！顺便说一句，我有一个更新版本的方程，我应该给您。基本上： D = (Vn + Vf) / (Ei + Em) Vn = 现在价值 Vf = 未来价值 Ei = 实现成本 Em = 维护成本 随着时间减少到： D = Vf / Em -Max

回复

Mike Spooner 说：2011年7月21日上午2:12 关于“允许通货膨胀”的话题，记住价值和价格之间有区别。价值可以是恒定的，而价格变化。

回复

Understanding the value of software | Software Dev 2k 说：2011年10月25日上午2:53 […] 最近发现了 Max Kanat-Alexander 的这篇帖子，它试图创建一个数学公式来确定是否 […]

回复

George Kalfopoulos 说：2011年10月25日上午2:57 相当迷人的阅读。 几天前我写了一篇更通用的关于软件价值的文章（如果有人关心，可以在这里找到 http://softwaredev2k.com/2011/10/understanding-the-value-of-software/），我今天更新了它，链接到这篇帖子，为更数学倾向的人。 确实很棒的工作！

回复

The Laws of Software Design « The Laughing Programmer 说：2013年5月3日上午6:52 […]（公式在他的网站上已经改变）。 […]

回复

Code Simplicity Book Review | Tipping Point Media Studios 说：2016年8月14日下午5:52 […] 2. 软件设计方程：（这里是一篇详细博文解释这个古怪方程-链接） […]

回复

What Makes a Great Developer Experience? » Code Simplicity 说：2025年4月15日上午3:03 […] 记住，在软件中，减少维护成本比减少创建成本更重要。所以您必须考虑您的工具的不仅即时影响（和即时 […]

回复