为什么要这样做呢？

    一般说来，你越不及时地杀虫，杀虫的代价（时间和金钱）就会越高。比如，你写程序时打错了一个字，编译器马上告诉你，你很容易就把它改正。你刚写好的程序在第一次运行时发现了一个问题，你也很快就能解决它，因为你对你刚写的程序还记忆犹新。如果你运行你的程序时发现了一个问题，可这个程序是几天以前写的，你可能就需要折腾一会儿，还好，你还大致记得，所以不会花太长时间。但如果你在你几个月以前写的程序里发现了问题，就比较难解决了，因为你已经忘了许多细节。这时候，你还没准儿正忙着杀别人程序里的虫呐，因为这家伙到加勒比海阿鲁巴岛度假去了。这时候，解决这一堆问题的难度不亚于从事尖端科学研究。你一定得小心翼翼地，非常系统化地从事，而且你很难知道多长时间你才能把问题解决。还有更糟糕的，你的程序已交到用户手里了，才发现问题，那你就等着套腰包吧。

    总结起来，就一条：越早解决问题，越容易解决。

    另外还有一个原因，刚写的程序里发现问题，你能够比较容易地估算解决它的时间。举个例子，如果我问你写一段程序去把一个列表排序需要花多长时间，你可以给我一个比较确切的估计。如果你的程序，在Internet Explorer 5.5安装以后，工作不正常。我问你要多长时间把这个问题解决，你恐怕都估计不出来，因为你根本就不知道是什么原因造成了这个问题。你可能要花三天时间才能解决，也有可能只花两分钟。

    这个例子告诉我们，如果你的开发过程中有许多虫没有及时解决，那你的开发计划肯定不可靠。反过来，如果你们已经把已知的虫全部解决了，要做的事只是写新的程序，那你的开发计划就会比较准确。

    把已知的虫全部解决，这样做还有一个好处：你可以对竞争对手快速反击。有些人把这叫着“让开发中的产品随时处在可以交给用户的状态”。如果你的竞争对手推出一个新的功能想把你的客户抢走，你可以马上在你的产品里加上这个功能，立刻将新产品交付用户，因为你没有一大堆积累下来的问题要解决。

    6. 你们的产品开发日程安排是否反映最新的开发进展情况？ 

    为什么我们需要开发日程安排？如果你的程序对公司的业务很重要，那公司就必须知道你的程序何时能写完。满世界的程序员都有一个通病，那就是他们都搞不清自己何时才能写完要写的程序。他们都只会对管理人员嚷嚷：“等我做好了就做好了！”

    不幸的是，程序写完了，事远远没完。作为一个公司，在发行产品之前，还有许许多多的事情要做：何时做产品演示？何时参加展览会？何时发广告？等等。所有的这一且都依赖于产品的开发日程安排。

    定下产品开发日程安排，还有一个很关键的好处：它逼着你只做叫你做的功能，甩掉那些可要可不要的功能，否则这些可要可不要的东西有可能把你缠住。请看featuritis 。

    定下产品开发日程安排，按照它开发，这并不难做，请看我的另一篇文章 Painless Software Schedules ，这篇文章告诉你一种制订产品开发日程的好方法。

    7. 你们有没有软件开发的详细说明书？

    写软件开发的详细说明书就像是绣花：人人皆知是好东西，可没谁愿意去做。

    我不知道这是为什么，也许是因为多数程序员天生就不喜欢写文章。其结果是，一个开发组里的程序员们，宁可用程序来沟通，也不愿写文章来表达自己。他们喜欢上来就写程序，而不是写什么详细说明书。

    在产品的前期设计过程中，如果你发现了一些问题，你可以轻易地在说明书里该几行字就行了。一旦进入了写程序的阶段，解决问题的代价就要高得多了，不仅仅是时间上的代价，而且也有感情上的代价，因为没人愿意将自己做成的东西扔掉。所以这时候解决问题总有一些阻力。

    没有产品开发详细说明书就开始写程序，往往会导致程序写的乱七八糟，而且左拖右拖不能交付使用。我觉得这就是Netscape遇到的问题。前四个版本的程序越写越乱，以至管理人员作出一个愚蠢的决定：把以前的程序统统扔掉，重新写。后来他们在开发Mozilla时又犯了同样的错误。产品越做越乱，完全失控，花了几年的时间才进入内部测试阶段。

    我最得意的理论是：如果让程序员们接受一些写文章的训练如an intensive course in writing，他们就可能会改变一下不写说明书的坏习惯，而以上所说的糟糕的例子就有可能少发生。

    另一个解决问题的办法是：雇一些能干的项目主任，专职写产品开发详细说明书。

    不论采用以上哪种方法，道理只有一个：在没有产品开发详细说明书之前，决不可写程序。

    如果想更多了解这个话题，可以读我的四篇文章。

    8. 你们的程序员是否工作在安静的环境里？

    当你让你的智囊们工作在安静，宽敞，不受人打扰的环境里，他们往往能更快地出活，这已是不争的事实。有一本经典的讲软件开发管理的书Peopleware 把这个问题阐述得很清楚。

    问题在于，我们都知道最好不要打断这些智囊们的思路，让他们一直处于他们的非常好的状态中，这样他们就能全神贯注，废寝忘食地工作，充分发挥他们的作用。作家，程序员，科学家，甚至篮球运动员都有他们的非常好的状态。

    问题还在于，进入这个非常好的状态不容易。我觉得平均起来，需要１５分钟才能进入非常好的状态，达到最高工作效率。有时侯，当你疲劳了或已经高效率地干了许多工作了，你就很难再进入这个状态，只好干点杂事打发时间，或上网，玩游戏等。

    问题更在于，你很容易就被各种各样的事打扰，被拽出你的非常好的状态：噪音啦，电话啦，吃午饭啦，喝杯咖啡啦，被同事打扰啦，等等。如果一个同事问你一个问题，只花你一分钟，可你却被拽出你的非常好的工作状态，重新回到这个状态需要花半小时。你的工作效率因此而受到很大影响。如果让你在一个嘈杂的大房间里工作（那帮搞网站的家伙还就喜欢这样），边上的推销员在电话里大叫大嚷，你就很难出活，因为你进入不了你的非常好的工作状态。

    作为程序员，进入非常好的工作状态更难。你先要把方方面面的细节装在脑子里， 任何一种干扰都可能让你忘掉其中某些东西。你重新回来工作时，发现好些东西记不起来了（如你刚用的局部变量名，或你刚才的搜索程序写到哪里了等）你只好看看刚写的程序，回忆一下，慢慢地回到你刚才的非常好的工作状态。

    我们来做一个简单的算数。假设一个程序员被打扰一下，哪怕只有一分钟，他却需要花１５分钟才能回到非常好的工作状态（统计资料显示如此）。我们有两个程序员：杰夫和愚夫， 坐在一个大办公区里工作。愚夫想不起来用什么函数去进行Unicode 字符串复制。他可以花３０秒查一下，或者花１５秒问杰夫。由于他坐在杰夫的旁边，他就选择去问杰夫。杰夫被打扰了一下，耽误了他１５分钟，节省了愚夫１５秒钟。

    现在，我们把他们俩用墙和门隔开，让他们俩分坐在不同的办公室里，愚夫又想不起来什么涵数名，自己查一下要花３０秒；问杰夫，要花４５秒，因为他要站起来走过去问（对这帮程序员来说，这可不是件简单的事，看看他们的体质就知道为什么了）。所以他选择自己去查。愚夫损失了３０秒钟，可是杰夫少损失了１５分钟。哈哈！