一条在软件、设计、系统领域被反复提起的定律。1984 年前后由 Larry Tesler 提出，原文短到只有两句话。此后三十多年里，从对象数据库、设计模式、业务流程到营销、机器人，各领域的作者以各自的方式重新陈述过这条定律。
The Law of Conservation of Complexity
原始表述约 1984 年。
“Every application has an inherent amount of irreducible complexity. The only question is who will have to deal with it—user, application developer, or platform developer.”
每个应用都有固有的不可消除的复杂性。问题在于谁承担这份复杂度。用户、应用开发者，还是平台开发者。
想进一步讨论，可参见 Dan Saffer 的访谈。以下是各个视角。
各个视角
对象数据库视角
“在这里，对象引用在磁盘间移动时的管理复杂度，从程序员手里被移交给了系统。复杂度并没有被消除，只是被移动到了别处，这样程序员就能把精力集中在应用本身的问题上。”
Tim Andrews 著《Object Databases in Action · Technology and Application》。Richard Y. Wang 主编，Information Technology in Action · Trends and Perspectives 第四章，第 63-82 页，1993 年 2 月。
模式设计视角
“复杂度守恒定律是对‘模式祭司’（Pattern Priesthood）的一种平衡。挑选模式时，要选那些有足够实质、值得下本钱的，同时不能复杂到只有少数精英才看得懂。”
Linda Rising 著 The Patterns Handbook · Techniques, Strategies, and Applications，第 350 页，1998 年 6 月 28 日。
用户体验视角
“既然我们要不断降低暴露给用户的复杂度占比，那可以预期我们自己任务里的难度和复杂度，会随着时间推移只增不减。”
Bruce Tognazzini 博客文章，1998 年 9 月。
应用开发平台视角
“SAP CAF 的目标，就是把开发复合应用时的复杂度，尽可能从程序员那边转移到工具本身。”
Dan Woods 与 Jeffrey Word 著 SAP NetWeaver For Dummies，第 267 页，2004 年 5 月 7 日。
产品形态视角
“从自适应帆配置（transition rig，一种可自适应的帆船结构）来看，复杂度已经从产品使用环节转移到了设计与制造环节。在很多情况下，这是一个值得做的取舍，尤其对成熟产品而言，不管是软件界面、物理操控，还是网站本身。”
David Bishop 博客文章，2005 年 1 月 27 日。Peter Lucas、Joe Ballay 与 Mickey McManus 著 Trillions · Thriving in the Emerging Information Ecology，第 149 页，2012 年 8 月 29 日。
业务流程视角
“业务流程的复杂度就像能量，无法被创造也无法被消灭，只能从一个地方被转移到另一个地方。”
Sean McGrath 在 ITworld 发表的文章，2005 年 5 月 19 日。
交互设计视角
“用 The Who 在 1966 年的那首《Substitute》唱的那句。你看到的简单事情，实际上全都是复杂的。”
Dan Saffer 著 Designing for Interaction · Creating Smart Applications and Clever Devices，第 55 页，2006 年 7 月 28 日。
软件集成视角
“概括起来，尤其是在人机交互的语境下，似乎存在一个复杂度守恒的原则。数字化表示与计算中的复杂，只能在牺牲显式表示的前提下被简化。”
Kay Hammer 与 Tina Timmerman 著 Fundamentals of Software Integration，第 112 页，2007 年 12 月 11 日。这一条是对该定律的独立提出。另见第 270-271 页。
讨论方式视角
“谈论一件事简单，却不去看那些不可避免的复杂最终由谁承担，就等于直接跳进泥坑里。”
Bill de hOra 博客文章，2008 年 8 月 15 日。
产品成功背后的原理
“如果我们去看历史上那些最成功的应用，就会发现背后站着 Tesler 定律。”
Mark Mzyk 博客文章，2008 年 8 月 17 日。
组织与工程分工视角
“能量永不会损失。同理，一个系统为实现目标所必需的最小复杂度也无法被削减，它只能被移动位置。”
Eachan Fletcher 博客文章，2008 年 8 月 25 日。
“这也是组织结构里的一个因素。如果有人，或某个部门，做得少了，就一定有人要多做，否则结果不会出现。”
Eachan Fletcher 博客文章，2008 年 9 月 3 日。
架构分层视角
“软件系统中的总复杂度始终守恒，可以在不同层级之间移动。把它放在哪里，是一个架构选择。”
Dino Esposito 与 Andrea Saltarello 著 Microsoft® .NET · Architecting Applications for the Enterprise，第 368 页，2008 年 10 月 15 日。这一条是对该定律的独立提出。
认知工作分析视角
“这种复杂度的转移在自动路径规划中就能看到。最优路线的计算由计算机而不是人类用户来承担。”
Daniel P. Jenkins、Neville A. Stanton、Paul M. Salmon 与 Guy H. Walker 著 Cognitive Work Analysis · Coping with Complexity，第 8 页，2009 年 1 月 1 日。
健康信息系统视角
“软件厂商把所有技术复杂度都留给了用户。要真正达到理想的可用性水平，唯一的办法是设计反映用户工作流程（workflow）的软件，以及反映用户心智模型（concepts）的术语。”
Alan R. Shark 与 Sylviane Toporkoff 著 eHealth · A Global Perspective，第 125 页，2010 年 3 月 17 日。
学习设计视角
“那些机械照搬 Cognitive Load 原则来设计工作培训项目的人，大概相信自己把学习的‘不可消除的复杂性’承担了下来，其实他们可能只是在推迟学习本身的困难。学习没法替别人完成，正如没法替别人吃饭或喝水。”
Bunchberry & Fern 博客文章（已归档），2010 年 3 月 25 日。
用户体验设计视角
“创造简洁用户体验的秘诀，是把复杂度放到合适的位置，让每一刻都感觉简单。”
Giles Colborne 著 Simple and Usable Web, Mobile, and Interaction Design，第 180 页，2010 年 9 月 26 日。
日常技术视角
“汽车和它的车载计算机系统每年都在变得更复杂，但这种隐藏的复杂度改变了驾驶员的任务，把它变得更简单，也更安全。”
Donald Norman 著 Living with Complexity，第 224 页，2010 年 10 月 29 日。
设计教学视角
“随着系统呈现出来的复杂度被减轻，设计师自己任务里的复杂度必然要增加来填补这个空缺。对于愿意迎接这项挑战的设计师，以及今天在校园里学习交互设计的学生而言，这是好消息。”
Robert Blinn 对 Norman 那本书的评述，2011 年 2 月 1 日。
微交互视角
“先定位核心复杂度在哪里，然后决定用户希望在整体流程的哪个环节接触到其中的哪一部分。”
Dan Saffer 著 Microinteractions · Designing with Details，第 67-69 页，2013 年 5 月 20 日。
营销视角
“工程师可能要多花很多个小时，才能为用户每次节省几秒钟，但按 Tesler 的说法，这是合理的取舍。我建议营销领域也用同样的模型。”
John Kuefler 博客文章，2015 年 11 月 4 日。
机器人工程视角
“复杂度因此从物理基础设施转移到了算法层面。”
Raffaello D'Andrea 向 Kyle Chayka（The New York Times Magazine）阐述机器人辅助的机场行李方案时总结的话，2016 年 11 月 10 日，第 58 页。