提高质量为何如此之难

提高质量为何如此之难
Precision Cribbage 的故事说明，"符合需求"并非是质量全部含义--除非你接受的是某种关于需求的非传统定义。这个故事同时也说明，基于错误的数量来定义质量也是不全面的--这方面的例子有：

所谓质量，就是指没有任何错误。

虽然实际上这类定义不堪一驳，但是许多年来它们一直是人们关于高质量软件的主流认识。在这种意识的支配下，软件开发人员及其主管们对提高软件质量的要求置若罔闻。难道他们不愿意去提高质量吗?即使没有其他人向他们提出这种要求，哪怕仅仅是为了满足自己的自尊心，他们也应该这要去做呀？毫无疑问，他们的确愿意提高质量，但是事实并非如此--原因何在？
"还不算坏"效应
CozyWrite 和Cribbage 只不过是两个典型的故事，我还能举出成百上千的这类事例；我一点也不怀疑，你也可以举出许多这样的例子。如果你问一下软件开发人员："你们是否对高质量的软件产品有兴趣？"我敢肯定，出于其职业的自尊心，他们一定会回答说："当然！"
然而，假设你要是向他们专门询问一下CozyWrite 或Precision Cribbage 的改进问题，其开发人员将会回答："但是，它已经是一个好的产品了呀。其中的确有错误，但是这是很自然的事，所有软件都存在问题。而且，（既然用户愿意购买它，就说明）它总要比竞争对手更好一些。"很自然地，下面的三句话的正确性都是可以证明的：
1. 用户的确在使用他们的软件产品，而且因此很高兴，所以这个产品是高质量的；
2. 没有哪个软件没有错误（至少我们还不能证明其反面）；
3. 用户是在对多种相互竞争的产品进行比较之后才确定购买它的，这说明用户认为它相对更好。
在这种环境之中，除非有来自外界的推动力，否则开发者自身不会有多少积极性去提高软件质量。比如说，要是用户不再使用或者不再购买其软件产品，那么开发者才可能会决定去改进质量--但是也许已经为时太晚。如果出现了一个管理体制更为高效的竞争对手，那么原来销售软件的企业就只有淡出市场的份了。
但是对于那些服务于某个更大企业的内部软件开发部门而言，他们几乎不会面临多少竞争，因此这种部门的前景注定会日渐萧条。这种萧条是否重要，取决于其上层企业对"质量"的定义。如果上层企业能够获得其所需要的价值，而且也不知道还有更好的途径，这种萧条的状况将一直持续下去。但是一旦其所从属的上层企业开始不满起来，危机就将发生。
"这不可能"效应
你是否知道，要是你有八英尺六英寸高，你就可以被NBA 的一支球队中聘为首发中锋，并且因此每年可以挣到3,000,000 美元？现在你已经知道了这一点，那么为什么不马上开始一个增加身高的计划呢？这种问法幼稚得可笑，因为你并不知道如何才能使自己长高几英尺。
你是否又知道，要是可以把你的软件中的错误数量减少至每一百万行代码中不超过一个，你的软件市场就会每年增加3,000,000 美元的份额？这种问法同样幼稚得可笑，因为你并不知道如何才能把自己的软件中的错误数量降低到每一百万行代码中不超过一个。
在他的" Quality Is Free"5 一书中Philip 说过，提高质量的积极性总是来自于对质量的代价（我更偏爱使用"质量的价值"一词，虽然二者的意思完全一样）的分析。在我的咨询经历中，我经常要与深受困扰的项目主管们交谈，他们之所以有所烦恼，大多是因为他们企图削减软件的开发费用，或者缩短开发周期；但是，我却很少遇到哪位主管为软件质量的提高烦恼过。他们不用大伤脑筋，就可以轻松地告诉我为了削减费用或加快进度，那些工作才是应该做的；然而，对于提高软件质量所能带来的价值，他们却似乎从来也没有考虑过去评估一下。
而当我建议他们评估一下质量带来的价值时，他们通常的反应让我感觉到，自己好像是在告诉他们长高到八英尺六英寸之后的价值--对他们来说，提高质量是"挟泰山以超北海"的工作。既然对如何实现这个目标一无所知，又为何要因为对其价值的评估而自寻烦恼呢？即使知道如何评估，但是既然我们对这种价值并不认同，那么又有什么必要去实现它呢？图1-3 显示出了这个恶性循环的过程。这里采用的是作用图的形式，我将在稍后对这种图表进行解释，并且将在本卷中一直使用它。现在，让我们暂且特别留意它是如何解释提高质量的工作的开展为何这样举步维艰。

图1-3 一种恶性的循环，它导致开发组织无法着手提高软件质量
对图1-3 中图表的解释仁者见仁，可能得出乐观的结论，也可能得出悲观的结论。从乐观的角度来看，这张图表说明，一旦开发组织开始领悟到质量的真实价值，其改进质量的积极性就会提高，进而可以促进其更好地理解如何才能提高质量，最后反过来使其更好地理解到质量的价值。Crosby之所以不惜付出质量分析的代价以改革开发组织的行政机制，原因正在于此。
尽管如此，从悲观的角度来看，这种循环也可以理解一种阻碍作用，它会阻碍以更高质量为目标的改革。如果不能意识到质量的价值，实现质量的积极性就是无本之木；反过来，对实现质量的方法的理解也就无从谈起。既然连实现质量的途径都不清楚，那么评估其价值又有什么意义呢？
锁定效应
图1-3 也恰好是说明锁定效应的一个例子。一个被锁定的系统会尽力使自己维持在现有的运行模式上，纵然有很多合理的原因要求改变它，该系统依然故我。关于锁定现象，最佳的例子莫过于标准编程语言的选择。无论是由于何种历史原因，一旦某个企业现在正在使用某一种编程语言，那么就需要花费更大的代价才能使之更换成另一种语言；在试图考察其他可替换语言的价值时，该企业的积极性也会同时下降；因此，根本就不可能知道如何去更换编程语言。其后果是，该企业会死抱目前正在使用的语言不放--这就像在选择车辆靠左还是靠右行驶的规则时，不同国家会固守自己现有的约定。
在本卷书中，我们将会看到很多有关锁定情况的例子；但是在目前，我们首先只需注意到这样一个事实：锁定现象都是连锁式发生的。要是你锁定于某一特定的编程语言，那么你同时也很可能会所定于下面的全部或者部分方面：
支持该编程语言的一整套软件工具
支持该语言的某种非标准变体的硬件系统
由若干特定的学校培训出来的人力资源
从其他某些特定的企业聘用来的人力资源
精通该语言及其工具的一群顾问
由使用该编程语言的其他用户组成的团体
一批通过改编程语言步步升迁的主管
面向该编程语言的专业书籍以及技术培训
与该编程语言对应的软件工程基本理论
与该编程语言对应的用户界面基本理论
按照上面的次序，这些因素将依次使得相应的企业锁定于其后续的因素。如果你试图改变其采用的标准编程语言，就会在整个企业的范围内造成一些列连锁反应，在其中的每一环节，你的努力都会遇到各式各样的阻力。
对于一个开发组织而言，调整其采用的标准编程语言究竟有无益处，这个问题并不重要。正如临床医学家Virginia Satir 经常挂在嘴边的一句话所说的：
"在选择工具时，人们优先挑选的并不是最适用的，而是自己最熟悉的。"