1. 从《失灵》说起
前段时间，我正好读了一本奇书《失灵 (豆瓣)》， 作者是一位出生在南非的犹太移民，后来到美国读物理学博士，然后又转行华尔街，作为宽客，创作了业界广为采用的某某局部波动率模型。这本书谈到了南非种族 隔离、犹太复国运动、物理学发展史、还包括叔本华和斯宾诺莎的哲学与伦理学。其主旨却是为了探讨：为何看来可靠的模型最终都会失效？
作者在这本书里，谈论了非常非常多的东西，但是其核心思想，是站在一个物理学家的立场，吐槽所谓的“模型”，特别是“经济学模型”。
作者在谈论模型时，这么说到：“模型是隐喻，并不是真实物体本身……模型就像一幅漫画，突出某些特点，而忽视了其他特点……模型减少了世界的维度，将多维世界缩小为更易理解的空间。”
与此相对的，则是理论。作者将其与模型做了对比：“模型是类比，借助别的事物来描述目标物体，因此模型需要解释。相反，理论不需要借助别的事物，只需要证实而不需要解释。理论阐释的是事物的本质，理论如果成立，就是事实。”
“如果理论成立，则能非常精确的描述其对象。”与此相对的：“模型经不起推敲”
接下来，不再引用书中的内容，说说我的理解：理论，尤其是物理学的理论，是非常“坚硬”的，与现实一对照，要么几乎一模一样，要么撞的粉碎。而物理之外的那些所谓的模型，看起来也是些数学公式、图表，像模像样。但却是柔软的，易变的，可以不断通过修正来修补和再解释的。
在软件工程领域，却正好充斥了种种隐喻构成的所谓模型。
2. 从隐喻到定论
在9年前的2005年，我曾经在 JavaEye 现在的 ITEye 连载过一篇文章，名叫《定论——软件开发的方法论探讨》。在那篇文章里，我提出了与《失灵》相当类似的看法，先摘录几段在下面：
事实上，所有的隐喻都不够好，都会扭曲软件开发过程的真相，都会使我们对软件开发的过程产生误解。
为 什么会这样呢？为什么一个挺像软件开发的隐喻会最终误导我们呢？原因在于一个隐喻是一个完整的场景，这个场景中有很多相互交织的“概念要素”。当这些要素 有很多在软件开发中出现时，我们就会认为这个隐喻很贴切，而当一个隐喻越是贴切时，这个隐喻中的其他一些在软件开发中不存在的要素，或者与软件开发相矛盾 的要素，就会打扰我们的分析，干扰我们的判断。使得我们不再思考软件开发本身，而是将思考建立在某个隐喻的场景中。这样思考得到的结果，肯定存在着误导的 可能。再由于不同的隐喻互不相容——你无法想象一群工匠去建设现代化的高楼大厦，他们最多只能造些平房——因此，建立在各种隐喻基础上的软件开发，至今没 有找到适合自己的方法论，倒是不同的隐喻之间互相打得火热。
软件开发有那么多方法，有那么多过程，那么多“最佳实践”，但是却从来没有定论，为什么没有定论呢？因为软件开发的“方法学”还处于蒙昧的“隐喻时代”，各家各派，都从自己的隐喻出发来看问题，所谓“鸡同鸭讲”，指的就是这种情况。
我们的目标，不应该去寻找各种隐喻，而应该须寻求定论！所谓的定论，应该建立在坚实的理论基础之上，而不是靠各种猜想与比喻来搞那些「高科技迷信」。
但是，当年我写的那篇文章，事实上却草草收场，并没有写完，因为见识不足，思考无法深入下去了。在当年那篇文章的结尾，我写了三个观点：
1、现有的软件开发方法，都不是定论，不过是你说你的好，我说我的好罢了。要能够得到定论，必须要有一种能够判断方法好坏的方法。也就是说，能够判断一个方法，用或不用，有多少好处。几个方法比较，哪个能够胜出的“检验标准”。
2、要能够检验软件开发方法的优劣，必须基于对于软件开发本质的正确认识，这样才能量化两个因素：软件需求的复杂程度以及软件开发的实际工作量。而现在的软件复杂度的度量，并未区分“需求”与“实际”的不同，或者“代码行数”，或者“功能点”，都是如此。
3、在能够正确度量需求复杂度与实际工作量之后，我们会发现，过去那么多号称是为了保证软件顺利开发的手段，往往只会坏事，耽误事。但是，完全不提前设计的方法，也并不可取。
3. 真实的研发究竟是怎么样的？
现在看来，当年我写的这三条结论，既有正确的成分，也有不足之处。
- 真实的研发过程，不仅仅是一个团队，在一个特定的时间段里，满足一组特定的需求。
- 真实的研发行为，不仅仅是通过量化需求的复杂度与实际开发工作量，来做出描述。
- 真实的研发行为，不能仅仅考虑这些，他们必须关注更多……
<未完待续>
ps: 附上当初《定论》的几个 link