今天白天开车的时候，一路在听唐纳德·A·诺曼的《设计心理学2：如何管理复杂》 (Living with complexity)。他的设计心理学系列书籍之前都看过，之所以再次翻出来，是因为最近的一系列工作，让我又重新思考简单与复杂之间的关系。

现代主义建筑大师路德维希·密斯·凡德罗(Ludwig Mies van der Rohe)说，Less is More，这句话几乎已经成为设计界不容挑战的金科玉律，其影响从建筑界直达科技界，甚至上升到了人生哲学的高度。

在诺曼博士的设计心理学套系里，虽然《如何管理复杂》这本书的评价并不算高，但我认为还是非常有价值的，它的价值不在于方法论，而在于对简单和复杂的理解。

拥抱复杂

首先，诺曼博士告诉我们，复杂是必需的，复杂是世界的真实状态，简单则是存在于脑海中的。

这其实和开发与业务规则有关的IT系统有些相像——首先，我们永远不能低估和回避复杂性。事实上，很少有不复杂的业务规则。就像书中提到的美国棒球运动，它的规则手册超过200页，定义的术语超过13页——这就是事物本身的情况，或许这些规则有简化的空间，但我想或许也很难大幅度地简化——我们很难刻意回避复杂性。

IT系统开发的风险之一，就是在开发之初，低估和回避了业务规则的复杂性。例如，这个系统要做的很简单，就是XXXX——或许要做的真的很简单，但更常见的情况是，事情其实并不简单，我们只是通过简单的描述，回避了复杂的业务规则梳理，复杂的例外情况了解和复杂的基本概念澄清。

不回避复杂，主动了解复杂，是必需的。

在何种层面分配和处理复杂

书中提到一个有趣的定律：特斯勒德复杂守恒定律 (Tesler’s Law)：

几年前，拉里·特斯勒（Larry Tesler），后来苹果公司的副总裁，认为系统的复杂性的总量是一个恒量：当你使人的互动行为更简单，那么隐藏在幕后的复杂性就增加了。特斯勒说道，把系统的一部分变得简单，那么剩下的部分就会变得更加复杂。这个原理就是今天所谓的“特斯勒的复杂守恒定律”。特斯勒形容这是一个平衡关系：使用户用起来更容易，意味着增加设计师或工程师的难度。每个应用程序都有固有的不可简化的复杂性。唯一的问题是，谁必须去处理它，是用户还是开发人员（程序员或工程师）？

嗯，到底是用户、设计师还是工程师应该处理这些复杂性呢？这是一个问题。

IT系统开发的风险之二，就是整个系统开发过程，并非三者利益一致的协同互动，而是一个复杂性转嫁的过程。用户希望设计师和工程师解决所有复杂性，设计师希望用户和工程师解决所有复杂性，工程师则希望用户和设计师解决所有的复杂性。即便三者的利益一致，在实际工作中，由于角色的不同，每个角色也还是会追问这一问题：到底由谁解决何种复杂性最有利呢？

这个问题确实难于回答，毕竟没有那么多集领域专家、设计师和工程师于一体的人存在。为每个角色配置最专业的人，在共同利益而非个体利益最大化的前提下，一道理解整个系统，分配复杂性，或许是一种解决之道。

从用户、设计师、工程师三种角色延展开来，更宽泛的，任何一个系统，都不能仅关注特定用户的需求，还应该关注商业本质，关注技术可以提供给我们什么，在三者中寻求统一。

边开车，我也边在想，关于What和How的问题，实质上，也是一个在何种层面分配和处理复杂的问题。事情总的复杂性不会因为复杂被代理委托 (Delegate)而减少，而是因为被合理分配和处理而提高了整个系统的效率。

站高一个维度处理复杂

Less is More不是说越简单越好，有时候真实世界就是如此复杂；而拥抱复杂也不是说复杂无需处理，有些复杂 (Complexity)可能会让人费解 (Complicated)。

IT系统开发的风险之三，就在于没有将主要精力用于真正思考和处理复杂。

复杂是一个中性词，既可能代表有意义（Meaningful)，也可能走向费解 (Complicated)。如何确保复杂不变成费解呢？解决之道是思考和抽象复杂，建立恰当的概念模型：就是面对复杂，不断分析和演绎，不断归纳和简并，将复杂问题抽象成为概念模型。在概念模型中，我们能清晰地了解每一个基本概念，以及其在真实世界中的投影，因而建立起极具美感的概念映射 (Concept Mapping)。

我想，事物都是相通的，之前提到人生算法，提到原则，从一个层面来说，原则，不正是我们面对纷繁复杂的世界，建立的与自身和谐统一的，极具美感的映射？

Less is More不是说越简单越好，Less和More也是中性词，正如听过的另一句话——简单是美的，复杂也可能是有意义的——全看我们如何理解简单和复杂。

Simplicity is Beautiful, Complexity is Meaningful.