这是加入ThoughtWorks之后，我学到的重要一课：用敏捷的方式、精益的计算和中庸的思想，来克服自己曾经有的很多偏执。特别要感谢郭晓和Michael Robinson的言传身教。

用一个实例来说明。在JavaEye的一个讨论中，作者说：“项目的设计阶段，把数据库扔在一边……在设计的时候不再是优先设计数据库的结构。而是先用一个空壳来做代替，完成业务逻辑的设计，业务逻辑稳定下后……设计数据库，然后优化数据库”。反对的声音说：“对于一个需要长期维护、持续添加新功能的系统，没有好的数据库设计，最终这个应用只能是一团糟，直到无法维护。”

似乎两边都很有道理。因为，确实两边都很有道理。

现在来模仿郭晓经常摆的一个手势：把两手张开，两只手就代表两个极端——右手是“完全以数据库设计来驱动软件设计”，左手是“完全以面向对象设计来驱动数据库设计”。而所有实际存在的策略，通常都是在两只手——两个极端——中间的某个位置。可能以前靠右一点，对数据库的规范比较重视；现在靠左一点，对领域模型比较重视。但可取的、经济的、实用的策略，通常不会是在某个极端：需要同时考虑两个方面，才能得到最好的效果。

中庸之道常常有效的深层原因是边际效用递减律：对一个方面的东西重视到一定程度以后，再加入更多的重视，收到的边际效用递减；同样的重视度放到另一个方面上，能够收到更大的边际效用。让每一分投入收到最大的回报，尽可能地消除浪费，这是精益的追求。而技术偏执，例如“面向对象终结数据库”或者“J2EE优于.NET”（以及它们的相反版本），容易让人忽视对边际效用的衡量而造成浪费——找不到投资回报率最高的解决方案。

敏捷也是一样。敏捷所追求的不是“简单”，而是“价值最大化”——消除浪费，精益。所以，尽管存在种种的误读，对敏捷宣言的正确解读应该是：在过去的数十年里，人们已经对右边的东西（过程、工具、文档、合同、计划）投入了足够多的重视，以致于再对它们投入更多的重视所能产生的边际效用已经相当低；同时人们对左边的东西（个人、交流、可工作的软件、客户协作、响应变化）投入的重视是不足的，在这里投入精力所能产生的边际效用更高。

为了获得更高的单位成本投入产出比，中庸之道往往是必须的选择。另一方面，对杠杆两端的价值进行比较通常是毫无意义的，因为不管缺了哪一端，你能得到的都将非常之少——如果不是一无所获的话。