← 返回规律列表
架构

意外后果定律

改变复杂系统时,应预料到计划之外的后果。

显示原始英文内容

Law of Unintended Consequences

Whenever you change a complex system, expect surprise.

Takeaways

  • No matter how well you plan, any significant change in a complex system can produce results you cannot anticipate.
  • Consequences can be unexpected benefits (happy surprises), unexpected drawbacks (side effects that hinder), or perverse results (the action makes the original problem worse).
  • In software engineering, this often manifests as a fix or new feature introducing bugs or performance issues elsewhere.

Overview

The Law of Unintended Consequences states that outcomes are not entirely predictable. Systems have complex interdependencies and human factors that can cause surprises.

Adding a new feature might unexpectedly degrade performance due to its interaction with an unrelated module. Simplifying a UI could lead to heavier backend load because users use the feature more often than expected.

It reminds engineers that systems are complex and our mental models are incomplete. When implementing changes, anticipate that "unknown unknowns" will crop up.

Examples

Enabling a new logging feature to help with debugging might fill the disk and crash the system, a perverse result relative to the goal of stability.

A social network changes its algorithm to boost user engagement, but as an unintended consequence, it amplifies outrage or misinformation. A bug fix in one part of the code unexpectedly causes a regression in another module that depended on the original bug behavior (overlap with Hyrum's Law).

Origins

Sociologist Robert K. Merton popularized the term in the 20th century, though the concept dates back further. In a computing context, it's more of a borrowed concept than a specific person's law.

Merton identified five sources of unanticipated consequences: ignorance, error, immediate interest, basic values, and self-defeating prophecy.

核心含义

复杂系统包含大量反馈回路、隐含依赖和局部优化。一个看似孤立的改动,可能影响性能、组织行为、数据质量或用户习惯。系统越大,越不能只依据改动者的局部模型判断结果。

小步发布、可观测性、灰度、回滚和事前演练,都是降低意外后果的办法。

实践例子

为了减少接口延迟,团队加入缓存,却让过期数据持续更久;为了提升指标,团队改变激励规则,结果成员开始优化数字而不是用户价值。

来源与边界

这是社会科学和系统思维中的广泛观察,并非软件专属定律。它不意味着不要改变,而是要求把反馈和撤销机制纳入设计。