看到如此高的比率，开发者通常会感到震惊，原因有二。首先，在开发过程中做修改比在维护时修改更容易。开发中的修改用于简化、精练代码，并改进代码的结构。通常，这些代码不会被看不见的手从很远的地方进行修改，因此它们不会包含一大堆难以琢磨的子程序调用。在大多数代价惨重的灾难中，都能看到这些程序间调用指令的身影。

　　第二，在开发阶段的错误变动导致的代价通常影响较小，因为修正这些错误并不会影响到现实中的操作。因此开发者并不会过多地关注他们的错误，也因此更容易低估错误发生的频率。

　　在开发过程中，你简单地修改一个错误后仿佛什么都没有发生过。不像是维护阶段，那时你必须为错误导致的破坏收拾残局，然后花费无数个小时在各种会议上解释，为什么这个错误不会再次出现了——直到它下一次出现为止。

　　由于这两个原因，开发者将维护过程中出现错误的高发生率归结为：这是无知的或者缺乏经验的维护程序员引起的。但是如果我们继续看看上述表格的下面几行，我们会发现，真正的起因既不是“无知”，也不是“缺乏经验”。

　　修改的行数 犯错的可能性

　　10.50

　　20.35

　　谁杜撰了这些听起来无辜的词语

　　而且又有多少次你听到那些程序员的经理同意这种论调？以至于“修改很微不足道时”，工作起来“仓促而粗劣（quick and dirty）”。

　　如果“微小”的变化真的很微小，这种“无所谓”的态度倒也无所谓——如果程序的维护工作像是公寓楼的维修工作的话。并不是说看门人的工作不会带来风险，但是看门人也可以这样假设；修理厨房水槽里的垫圈，并不会招致巨大的风险，不会导致建筑物的倒塌并且埋葬了所有的住户。不过，如果对每日运行着业务的程序也作这样的假设，非常不安全了。然而我们使用词语时过于随便和武断，“维护”一词在各种各样的场景下被滥用了。

　　无论是谁为计算机程序编写杜撰了“维护”这个词，他都是个有些粗心、缺乏思考的人，像那个训练军犬，让它听到命令“KILL”或“HELLO”去扑杀的那位驯犬师一样。作为“事后诸葛”，我建议“维护”程序员更应该充当脑外科医生的角色，而不是看门人——因为“打开”一个工作中的系统更像是打开人类的大脑，并换上一条神经，而不是掀开水池更换垫圈。如果维护工作被称为“软件脑外科手术”，它的管理还会容易么？

　　按照这种思路来思考。假设你有一个坏习惯——比如对一只军犬说“KILL”，你难道会对脑外科医生这么说么？“医生，撬开我的头骨吧，切掉这个小毛病。尽管做这一仓促而粗劣的工作吧——这不过是很小的变化！仅仅是一次微不足道的维护！”

　　职业精神

　　当然，作为咨询师的你，从来不会在语言上的如此粗心，不是么？但是，当你被正处于麻烦的客户——像细微的但损失惨重的维护修改——召集来时，要倾听他们“无辜”的语言。它所包含的线索是，你只需做很小的修改，能修正问题了。