软件工程中的熵增定律

参考连接

Software Entropy Explained: Causes, Effects, and Remedies

百度百科-热力学三大定律

热力学三大定律

软件复杂度论述里，需要引入热力学第二定律，为了不至于冷车启动，我们重温一下热力学三大定律

1. 第一定律

   能量守恒与转换定律是自然界的基本规律之一。

   自然界中的一切物质都具有能量， 能量不可能被创造， 也不可能被消灭； 但能量可以从一种形态转变为另一种形态， 且在能量的转化过程中能量的总量保持不变。

   • 热力学第一定律是人类在实践中累积的经验总结， 它不能用数学或其他的理论来证明

   公式为：

   $$U_Ⅱ - U_Ⅰ = \Delta U = Q - A$$

   或者

   $$Q = \Delta U + A$$

   公式中的变量为：

   变量	含义
   $U_Ⅰ$	系统初态 $Ⅰ$ 时的能量
   $U_Ⅱ$	系统初态 $Ⅱ$ 时的能量
   $\Delta U$	系统内能增量
   Q	外界对系统传递的热量
   A	系统对外界做功

2. 第二定律

   热力学第二定律是阐明与热现象相关的各种过程进行的方向、条件及限度的定律。

   由于工程实践中热现象普遍存在， 热力学第二定律应用范围极为广泛，诸如热量传递、热功互变、化学反应、燃料燃烧、气体扩散、混合、分离、溶解、结晶、辐射、生物化学、生命现象、信息理论、低温物理、气象以及其他许多领域。

   • 热不可能自发地、不付代价地从低温物体传至高温物体。
   • 不可能制造出从单一热源吸热、使之全部转化为功而不留下其他任何变化的热力发动机。

   方向性

   • 功可以自动地转化为热，功转热是不可逆过程

   • 热永远只能由热处传到冷处（在自然状态下）

     热量一定自动地从高温物体传向低温物体； 而反向过程， 热量由低温传回高温、系统回复到原状的过程，则不能自动进行， 需要依靠外界的帮助。

   熵及熵增原理

   这也是软件熵Software Entropie用到理论观点

   熵是与热力学第二定律紧密相关的状态参数。它是判别实际过程的方向，提供过程能否实现、是否可逆的判据， 在过程不可逆程度的量度、热力学第二定律的量化等方面有至关重要的作用。

   熵增定律，又称熵增加原理（principle of entropy increase）。在孤立系统内，任何变化不可能导致熵的总值减少，即 $ds \geq 0$ 。如果变化过程是可逆的，则 $ds = 0$ ；如果变化过程是不可逆的，则 $ds > 0$ ；总之熵有增无减 。熵增定律的表达式为：

   $$\int\frac\leq 0$$

   变量	含义
   $dQ$	热力学过程中吸收的热量
   $T$	为系统的热力学温度
   $\int$	积分表示热力学过程，当该过程可逆时取等号，不可逆时取小于号

   • 熵增定律是利用反证法进行证明的，具体证明这里不展开复述
   • 由于不可逆过程必然导致熵增，熵的大小可以作为度量这些无法参与热力学过程的耗散的程度。

   熵增定律的推论

   • 宇宙的能量（内能）是恒定的；
   • 宇宙的熵一直在趋于最大值，最后发展为热寂说

3. 第三定律

   不可能应用有限个方法使物系的温度达到绝对零度

   绝对零度不可能达到， 看来是自然界中的一个客观规律。这个规律的本质意义为， 物体分子和原子中和热能有关的各种运动形态不可能全部被停止。这与量子力学的观点相符合， 也符合唯物主义的观点：“ 运动是物质的不可分割的属性”。任何一种运动形态看来都不可能完全消失。

信息熵

为了更好的理解熵这个概念，我们简单说下信息熵是个怎么回事。

有一个前提共识，就是信息的本质是为了确定性。

另外一个就是，信息量的度量基准是二进制，单位是比特，至少这是信息论的基础。

以抛硬币来开始，假设都是理想的等概率分布，那么抛出去后，硬币的正反面分别是50%，在手揭开之前，我们不知道硬币是正面还是反面，只有揭开后，这个正面或者反面才确定。现在问题来了，如果我需要知道硬币的所有可能状态，就需要将它所有可能的状态都表述出来，映射到编码上，就是1和0，这两个值分别代表硬币的两种状态，那这个独立事件的信息量就是2.

再复杂一些，两枚硬币一起仍，切互不干扰，那么可能出现的状态就是2*2=4，信息量就是4.随着硬币的增多，复杂度也在增大，结果状态的信息量也一直在增大，而且这个结果一不可逆二一直在增大，只要孤立系统想要从一个平衡状态达到另外一个平衡状态，信息量就要增大，类似熵的放大意味着温度由高到低。

现实世界等概率的事件一般是不存在的，这个情况聪明的人类早就相出了办法，就是将不确定因素分割为许多个等概率的子事件即可。拿上面抛硬币的例子来说，比如有人对硬币做了手脚，正面的概率为80%，背面的概率为20%。这个抛硬币游戏可以转换为从一个袋子里摸球的游戏，背面的20%相当于在一个袋子里装着5个不同颜色的球，而你需要拿出指定颜色的球，这5个颜色的球的信息量就是 $\frac{1}{0.2} = 5$ ,同理背面的信息量为 $\frac{1}{0.8} = 1 + 0.25$ .0.25在工程学中是不可实现的，当然这并不影响我们对概念的理解。最后我们还需要将两个等概率系统出现的概率作为系数，然后才可以将两个系统的信息量相加，得出非等概率系统的信息熵。公式如下:

$$0.2 \times log_25 + 0.8 \times log_21.25 $$

由此我们可以推导出信息量公式

$$H = p_1 \times log_2(\frac{1}) + p_2 \times log_2(\frac{1}) + ... + p_i \times log_2(\frac{1})$$

最后得出

$$H(X) = \sum_^ P(x_i) \times log_2\frac{1}{P(x_i)}$$

也可以是

$$H(X) = - \sum_^ P(x_i) \times log_2{P(x_i)}$$

其中H(X)是总信息熵，P是特定事件出现x状况的概率。

可以从公式中观察出，事件复杂度的上升，信息熵也是只增不减，系统趋于新平衡的代价是信息熵的增加。

信息量和信息熵是信息论中两个相关但不完全相同的概念。

1. 信息量： 信息量是表示一个事件的不确定性或意外性的度量。对于事件 (E) 的信息量 (I(E))，通常用对数函数表示，具体公式为 $$(I(E) = -\log_b(P(E)))$$，其中 (P(E)) 是事件 (E) 发生的概率，(b) 是对数的底。信息量的单位通常是比特（在以 2 为底的对数中）或纳特（在以自然对数 (e) 为底的对数中）。

2. 信息熵： 信息熵是一个系统或分布的不确定性的度量。对于一个随机变量 (X)，其概率分布为 $(P(X=x_i))$，信息熵 (H(X)) 的计算公式为 $$(H(X) = -\sum P(X=x_i) \log_b(P(X=x_i)))$$，其中求和遍历所有可能的取值。信息熵是对整个系统的平均不确定性的度量。

简而言之，信息量通常用来衡量单个事件的不确定性，而信息熵则用来衡量整个系统或分布的不确定性。在某种程度上，信息熵可以看作是信息量的期望。这些概念在信息理论中用于分析通信、编码和数据压缩等问题。

在信息论里面，熵是对不确定性的测量。但是在信息世界，熵越高，则能传输越多的信息，熵越低，则意味着传输的信息越少。

通过信息熵公式，我们可以很快的预测出一个信息的压缩极限，也可以用这个公式检查压缩效果何如。如果未经压缩，一段英文文本的每个字母需要8个比特来编码，但是实际上英文文本的熵大概只有4.7比特。这是由于英文的编码包含了各式符号，如逗号、引号等。因此英文输入法使用了8个比特来表达一共256个字母及符号。

如果压缩是无损的，即通过解压缩可以百分之百地恢复初始的消息内容，那么压缩后的消息携带的信息和未压缩的原始消息是一样的多(状态可逆的前提是信息熵一样，这与热力学中的熵异曲同工)。至此，我们应该对熵这个概念有了一定的理解，下面可以开始熵在软件工程中的量度了。

熵与软件工程

什么是软件熵

和上面的信息论中的熵一样，软件工程引入熵的概念，也是为了衡量软件系统内在的不稳定性。

我们通常说一个项目在起始之初就要重视技术架构和业务架构，往往会有专业的架构师进行系统设计，需求分析以及实现路径。但是事与愿违的是，往往在项目之初，在大家都不注意的时候，熵增往往最快。

软件开发是一门艺术，也是一门行业，其核心构件并不明确。建筑工人使用水泥和钉子，而软件开发人员则使用逻辑断言和一系列假设。这些东西无法拿在手上检查，也无法按八分之一英寸排列。虽然旁观者可能会将软件开发与建筑相提并论，但除了一些表面的相似之处外，这样做只会适得其反。

尽管存在这些困难，我们还是可以制定出一些指导原则，使我们能够了解软件熵的来源，衡量其对我们的目标所造成的风险程度，以及（必要时）可以采取哪些措施来限制其增长。

软件熵的拟议定义如下：

$$E = I´C / S$$

• I´ 是由上一次开发迭代中引入的意外问题的数量得出的
• C 是现在对系统实施更改导致新的 I´ > 0 的感知概率
• S 是下一次开发迭代的范围。

一般来说，E 值低于 0.1 即为良好。0.5 的 E 值被认为是高值，而高于 1.0 的 E 值则是压倒性的。

开发迭代的概念与我们对软件熵的理解密不可分。迭代是从系统的一种行为到另一种行为的活动周期。我们在软件迭代过程中为自己设定的目标称为其范围。在软件开发中，这种循环涉及修改或扩展软件的底层代码。

对代码的所有修改都发生在开发迭代中，即使执行者并不这么认为。也就是说，那些以使用 "快速而肮脏 "的方法构建系统而自豪的小型企业，在很少或根本不收集需求或分析的情况下，仍然会使用开发迭代来实现他们的目标。他们只是没有计划迭代而已。同样，即使修改后的系统行为在某种程度上偏离了我们的意图，它仍然是通过开发迭代实现的。

事实上，这种风险正是我们对软件熵的认识所要解释的，也是我们测量软件熵的愿望所要限制的。因此，在实际应用中，我们可以将软件熵定义如下。

任何给定系统都有一组有限的已知开放问题$I_0$ 。在下一次开发迭代结束时，将有一组有限的已知开放问题 $I_1$ 。系统固有的熵决定了我们对$I_1$ 的期望值与实际值的差异程度，以及这种差异在后续迭代中的增长程度。

软件熵的影响

我们对软件熵影响的实际体验取决于我们与相关系统的互动方式。

用户对软件持有一种静态观点；他们关心的是软件当前的行为，而不关心系统的内部结构。通过执行预定义的操作，用户假设软件将以相应的预定义行为做出响应。然而，用户最不具备评估他们正在使用的软件中熵的能力。

软件熵与变化的概念紧密相连，在静态系统中是没有意义的。如果没有意图改变系统，我们就无法谈论它的熵。同样，一个尚不存在的系统（即下一次迭代实际上是其存在的第一次）也没有熵。

从用户的角度来看，软件可能被认为是有“缺陷”的，但如果在随后的迭代中软件开发人员和管理人员按计划实现了他们的目标，我们必须得出结论，系统中的熵实际上是相当低的！因此，用户的经验对于软件熵告诉我们很少，甚至可以说几乎没有。

• 软件开发人员对软件持有一种灵活的观点。他们关心系统当前的功能，仅限于必须进行更改，并关注系统的工作细节以制定适当的策略。
• 管理人员可能对软件持有最复杂的观点，既包括静态的又包括流动的。他们必须在短期的紧急需求和业务计划对未来的更远期需求之间取得平衡。

在这两种角色中的人都有期望。每当这些期望受挫时，软件熵就会显现出来。也就是说，软件开发人员和管理人员尽最大努力评估风险并为其制定计划，但是——除非有外部干扰——如果他们的期望仍然受挫，那么我们才能谈论软件熵。它是一只看不见的手，打破了不在范围内的组件交互，导致生产服务器莫名其妙地崩溃，并阻止及时且经济有效的热修复。

许多熵水平高的系统归因于特定的个体，特别是如果开发团队中有初级成员。这个人拥有的知识使得其他人无法在没有他的“宝贵”输入的情况下完成任务。这种知识无法在标准的UML图表或技术规范中体现，因为它包含了一系列异常、直觉和技巧。这种知识不依赖于逻辑一致的框架，因此很难——如果不是不可能——转移给其他人。

假设有这样一个组织，通过巨大的决心和努力，成功扭转局面并稳定了其IT部门。情况似乎有所改善，因为当软件开发陷入停滞时，任何进展都是令人鼓舞的。然而，实际上，与熵仍然较低时可以达到的宏伟目标相比，目前所达到的期望较低且成就不足为奇。

当软件熵压垮一个项目时，该项目就会冻结。

不会再有开发迭代。幸运的是，这种情况不是瞬间发生的。每个系统都会经历一种缓慢直到急剧走向悬崖边缘的过程。无论第一个版本组织得多么有序和高效，随着连续的开发迭代进行，它的熵——因此事物出现意外问题的风险——将会增长，除非采取具体步骤来防止它。

软件熵无法减少。就像现实世界中的熵一样，它只会增长或保持不变。起初，它的影响微不足道。当它们开始显现时，症状较轻，可以掩盖或忽视。但如果一个组织只在软件熵成为项目中主导风险后才尝试对抗它，它将不幸地发现其努力是徒劳的。因此，对软件熵的认识在其程度较低且不良影响最小的时候最有用。

这并不意味着每个组织都应该投入资源来限制其产品中熵的增长。今天正在开发的许多软件——尤其是面向消费者的软件——具有相对较短的预期寿命，也许只有几年。在这种情况下，利益相关者无需考虑软件熵的影响，因为在整个系统被抛弃之前，它很少会成为严重障碍。然而，还有一些不太确定的原因要考虑软件熵的影响。

试想一下,运作一款以互联网路由为基础设施将钱从一个银行账户转移到另一个账户的软件。在任何给定时间，这种软件的一个或多个版本都在生产中，它们的集体行为可以以相当高的准确性进行记录。

系统的风险容忍度是衡量我们从一个开发迭代到下一个迭代中可以舒适允许多少以及什么类型的意外行为的度量。对于刚才提到的这类系统，风险容忍度远低于例如路由电话呼叫的软件。而这种软件的风险容忍度又低于驱动许多商业网站的购物车的软件。

风险容忍度和软件熵之间存在关联，因为为了确保我们在下一次开发迭代期间保持在系统的风险容忍度内，软件熵必须保持最小**。**

软件熵的来源

软件熵原来认知匮乏，这是我们社会大众认知和现有系统实现之间分歧所导致的。这一点解释了为什么软件熵在修改现有系统的时候才有意义，缺乏认知进而带来实际影响。软件熵在一个系统中找到了最适合的土壤，这个系统的细节无法被单个人所理解，而是分散在开发团队中。时间也是认知强大的橡皮擦。

代码是一系列逻辑断言的表达。当软件的行为（因此是其代码）与其意图表达的逻辑不符时，我们可以谈论其固有的代码熵。这种情况可能以三种方式出现：

• 逻辑是众所周知的，但与其表达有分歧；

  这是最容易解决但也最不常见的情况。

  能是两个参与者维护的小系统，即开发人员和负责业务规划人员，属于这一类别。

• 对代码意图表达的逻辑有多种理解；

  人类的思维解释自己的经验，试图将它们过滤和修改以适应个人的框架。在没有有效的发展习惯的情况下——这些习惯基于自由交流思想、相互尊重和明确期望——关于系统当前如何运行的解释可能会与团队成员一样多。团队对当前开发迭代的目标本身可能会引起争议。

  许多开发人员通过加强他们对自己所需的理解以及系统“应该”如何组织来保护自己免受这种情况的影响。

  另一方面，管理者和其他利益相关者可能不由自主的试图改变其他团队成员的假设，以此试图让自己的生活变得更轻松，但往往却是错误的。

• 逻辑不是众所周知的。

  非常罕见的情况，实际上，开发迭代甚至无法开始，如果在某个时刻所有利益相关者都能达成一致，那么他们很可能会面临第一种情况。但还有其他因素需要考虑。一个组织可能声称采用了一种开发方法，但随后却随意放弃了其部分或全部方面。然后，软件开发人员的任务是完成模糊的任务，这些任务通常可以进行解释。改变其开发方法的组织特别容易受到这种现象的影响，尽管它们绝不是唯一的组织。管理层不知道或无法解决的个人冲突也可能导致期望与结果之间出现危险的背离。

我们现在已经找到了软件熵最常见的来源：对系统要表达的逻辑有多种、不完整的解释。由于这种逻辑只有一种表现形式，因此这种情况从定义上来说是有问题的。

这种知识匮乏是如何产生的呢？能力欠缺是一种方式。正如我们已经看到的，对下一个开发迭代的目标缺乏共识是另一个问题。但还有其他因素需要考虑。一个组织可能声称采用了一种开发方法，但随后却随意放弃了其部分或全部方面。然后，软件开发人员的任务是完成模糊的任务，这些任务通常可以进行解释。改变其开发方法的组织特别容易受到这种现象的影响，尽管它们绝不是唯一的组织。管理层不知道或无法解决的个人冲突也可能导致期望与结果之间出现危险的背离。

第二点就是，关于一个产品我们丢失相关的技术知识还有一个途径，转译（transfer）。即使对于最熟练的作家来说，在纸上获取技术知识也是一项挑战。原因是转录内容与如何转录同样重要。如果没有适当的规则，技术作家可能会记录太多的信息。或者，他们可能会做出一些假设，导致他们忽略了要点。技术文档生成后，必须小心翼翼地保持最新状态，这对于许多几乎在文档编写完成后就丢失的组织来说是一个困难的任务。由于这些困难，技术知识很少单独在文档中转移，而是以配对或其他形式的密切的人与人互动的形式转移。

每当大佬离开开发团队时，软件熵就会突飞猛进。他们带走了宝贵的专业知识。复制这种专有技术是不可能的，并且需要付出相当大的努力才能接近它。然而，只要有足够的关注和资源，就可以保留足够的知识，从而最大限度地减少系统熵的增长。

软件熵还有其他来源，但这些来源相对较小。例如，软件失效是指系统受到环境变化的意外影响的过程。我们可以想到它所依赖的第三方软件（例如库），但是还有其他更隐蔽的软件失效原因，通常是由于系统所基于的假设发生变化而导致的。例如，如果系统在设计时对内存可用性做出了某些假设，那么如果可用内存减少，系统可能会在意外时刻开始出现故障。

如何计算熵值

$$E = I´C / S$$

上面的公式已经列出，我们需要为式子中的变量 C、S 和 I 赋值。

• $I$ 是软件系统中未解决的行为问题的数量，包括缺少承诺的功能。

  这是一个已知数量，经常在 JIRA 等系统中进行跟踪。 $I´$ 的值直接从中得出。 $ I´$ 是在上次开发迭代期间被放弃或不完整的工作单元的数量，以及由于新引入的和意外的行为问题而产生的工作单元的数量。

  因为 $ I´$ 被算作多个工作单元，所以我们可以将其与 $S$ 的值联系起来， $S$ 是相同工作单元中下一个开发迭代的范围。 工作单元的具体组成取决于开发方法。

• $C$ 是当范围内的工作单元已实施时，下一次迭代中实际未决问题 $I_1$ 的数量将大于其现在估计的感知概率。该值位于域 0 <= C <= 1 中。

  有人可能会争辩说，概率 $C$ 正是软件熵所要测量的。然而，这个值与我们对软件熵的度量之间存在根本差异。出现问题的感知概率正是：它不是一个真实值。然而，它是有用的，因为参与项目的人的感受是关于项目稳定性的宝贵信息来源。

• 范围 $S$ 考虑了所提变化的大小，并且必须用与 $I'$ 相同的单位来表示。较大的 $S$ 值会降低熵，因为我们正在扩大建议更改的范围。尽管这听起来可能有悖常理，但我们必须记住，熵是衡量系统开发如何无法满足我们期望的指标。仅仅说熵是引入问题的机会的度量是不够的。我们自然会尝试预测风险，并在我们的计划中考虑它们（因此在我们对 $I_1$ 的估计中，它很可能会超过 0 ）。显然，我们对进行大范围的变革越有信心，系统中的熵就越小——除非那些计划变革和/或实施变革的人不称职。然而，这种可能性可能反映在 $I´$ 的当前值中。

请注意，我们不需要尝试指定 $I_1$ 的实际值与其预期值之间的差异大小。如果我们在制定计划时假设我们的计划是正确的，那么假设我们可以预测结果在多大程度上不符合我们的期望也是不合理的；我们只能指定一个感知到的机会 $C$ ，它不会。然而，实际值 $I_1$ 与其期望值的差异程度是以导出值 $I´$ 的形式在下一次迭代中作为熵计算的重要输入。

理论上， $I´$ 可能具有负值。但实际上，这种情况永远不会发生；我们通常不会意外地解决问题。 $I´$ 的负值并不是一个令人欣慰的信号。他们暗示计算熵的方法是有缺陷的。当然，可以通过采取具体措施来减少软件熵的增长，如下所述。然而，在这种情况下，我不应该假设负值，因为我们总是将我们的期望纳入我们的设计中。

$C$ 是主观值。它存在于开发迭代参与者的头脑中，可以通过对他们进行民意调查并对结果求平均值来推断。这个问题应该以积极的方式提出。例如：在 0 到 10 的范围内，最有可能的是 10，您将如何估计团队在本次开发迭代中实现所有目标的机会？

请注意，问题是针对团队的整体目标而不是其子集提出的。响应 10 表示 C 值为 0，而响应 7 表示 C 值为 0.3。在较大的团队中，每个响应可能会根据相关因素进行加权，例如个人参与项目的时间以及实际花费在该项目上的时间。然而，能力不应成为衡量回应的一个因素。不久之后，即使是团队中的初级成员也会意识到它在实现目标方面的效率。足够大的团队可能希望在对其余值进行平均之前丢弃最高和最低报告值。

询问专业人士他们的团队失败的可能性有多大是一个敏感且具有挑衅性的命题。然而，这正是任何希望量化熵的组织需要问的问题。为了确保诚实的答案，参与者应该匿名给出他们对 C 的估计，并且不用担心受到影响，即使他们报告的值非常高。

$S$ 必须在与 $I´$ 相同的工作单元中分配一个值，因此高度依赖于开发方法。对于采用敏捷方法论各个方面的团队来说，故事似乎是 $S $ 和 $I´$ 中最明显的工作单元。在这种情况下，开发迭代的范围涵盖每个定期计划的生产版本（无论是次要版本还是主要版本）。 $ I´$ 应该被量化为在发布之前的每个冲刺期间未成功完成的故事数量的总和，以及由于发布后出现的意外问题而生成的包含在未来冲刺中的故事数量。

请注意，我们不认为修补程序或其他计划外的生产版本定义了开发迭代的范围，也不应该从 $I´$ 中减去任何相关的故事。

这种方法的困难在于，必须先进行一段时间的发现和分析，然后才能将错误分解为故事。因此， $I´$ 的真实值只能在延迟后定义。此外，对 $C$ 的轮询自然会在每次冲刺开始时发生。因此，必须再次对整个发布范围内获得的结果进行平均。尽管存在这些困难，任何采用敏捷方法论方面的团队都可能会发现故事是量化 $S$ （因此也是 $I´$ ）的最准确单位。

目前还使用其他开发方法。无论采用何种方法，测量软件熵的原则都是相同的：应在发布到生产之间测量软件熵，应在相同的工作单元中测量 $S$ 和 $I´$ ，并且应从直接参与者处获取 $C$ 的估计值以非威胁性且最好是匿名的方式。

减少熵的增长

一旦丢失有关系统的知识，就永远无法恢复。因此，软件熵无法降低。我们所能做的就是抑制它的增长。

软件中熵的增长可以通过在软件开发过程中采取适当的措施来限制。敏捷开发的结对编程方面在这方面特别有用。由于编写代码时涉及不止一名开发人员，因此基本细节的知识是分散的，并且可以减轻团队成员离职的影响。

另一个有用的实践是生成结构良好且易于使用的文档，尤其是在采用瀑布方法的组织内。此类文档必须得到每个人都理解的严格且明确定义的原则的支持。依赖文档作为主要沟通手段和保护技术知识的组织非常适合这种方法。只有当没有关于如何编写和使用内部编写的文档的指南或培训时（在采用 RAD或敏捷方法 的年轻组织中经常出现这种情况），它们的价值才会受到怀疑。

有两种方法可以减少系统中熵的增长：执行旨在减少 $I´$ 的更改或执行旨在减少 $C$ 的更改.

第一个涉及重构。旨在减少 $I´$ 的行动本质上往往是技术性的，并且可能已经为读者所熟悉。必须进行开发迭代。此迭代中旨在减少熵增长的部分不会带来任何有形的商业利益，同时会消耗时间和资源。这一事实通常使得减少熵的增长在任何组织内都成为一个难以接受的事情。

降低 $C$ 的值是一种更有效的策略，因为效果是长期的。此外， $C$ 对于 $I´$ 与 $S$ 之比的增长起着重要的制约作用。减少 $C$ 的行动往往集中在人类的行为和思维上。尽管这些操作本身可能不需要开发迭代，但随着参与者接受并适应新程序，它们将减慢后续迭代的速度。就应该进行哪些改进达成一致这一看似简单的行为本身就充满了危险，因为项目参与者和利益相关者的不同目标会突然暴露出来。

总结

软件熵是指更改现有软件会导致意外问题、未实现目标或两者兼而有之的风险。

• 和信息熵之于信息一样，我们软件的本质是确定性，一个不确定不可用的软件是不能接受的

尽管在软件首次创建时可以忽略不计，但软件熵会随着每次开发迭代而增长。如果不加控制地继续进行，软件熵最终将导致进一步的开发停止。

然而，并不是每个项目都应该考虑软件熵的影响。在熵产生明显的有害影响之前，许多系统将停止生产。对于那些寿命足够长、熵构成可信风险的人来说，建立对熵的认识并测量其程度，尽管熵仍然很低，但提供了一种确保发展不会过早中断的方法。

一旦系统完全被软件熵的影响所淹没，就无法再进行任何更改，开发基本上就结束了。