对于软件项目经理来说，要求尽早交付产品，在巨大的压力面前，项目经理们该怎样做速战速决，完成任务呢，他们的面临的压力往往是巨大的。下面是一点建议。
假设你的团队有两名程序员，伯尼和罗布。两人都很能干，知识面相同，编程语言技巧也相当。你发现在开发过程中伯尼实现软件功能的速度远远超过罗布。
当伯尼着力于快速完成编程时，罗布正花时间写代码并对其进行重构。罗布对变量和方法的命名更擅长。一旦写的程序能够运行起来，他就把这个程序分成几小块。现在他要写测试来确保该程序的每一块都能按照他的意图运行。当他觉得结果比较满意时才宣称实现了功能。
但是假设你并不知道上述这些细节。如果你只看他们谁先宣称实现了功能，那么很明显伯尼表现得更好，对吗?
几个星期之后，你向客户演示这些功能。像往常一样，顾客喜欢你已经完成的功能，但现在需要你做一些改动和完善。你让软件开发人员修改这些代码。当你把新改进的功能带回给客户时，他们试用了罗布实现的功能，对他做出的改动十分满意。
遗憾的是他们发现伯尼实现的功能有些奇怪。当伯尼编写好新的功能后，一些以前能使用的功能现在却不能用了。客户把这些作为缺陷标记出来，然后你让伯尼来修改。客户又一次测试这些功能，结果后来新增的功能也不能用了。这到底是咋回事呢?
如果你有孩子，就会知道发生了什么。伯尼创建的是一个打地鼠式的应用程序。打地鼠是一种游戏，孩子们拿着一个木棒敲打几个孔中随意弹出的地鼠，他们会很惊奇接下来是哪个地鼠弹出来，而且还乐此不疲。然而，在修改应用程序的时候如果总有坏代码不知从何处随意弹出，那可不是好玩的事情。那会令人沮丧，结果也难以预料，并且它会减慢产品开发速度。伯尼一开始就全速冲刺，只是南辕北辙了。
尽管罗布从一开始就表现得较慢，但实际上他编写的代码更胜一筹。事实证明，他的节奏是可持续发展的。由于最初编写的代码就有较好的质量，所以，他才能更快地做出可行的改动。而且他早期编写的测试能随时带给他反馈信息，让他了解自己新写的代码是否与原有应用程序的其他部分兼容。
写高质量的代码和测试都需要花时间。当估计某一功能的实现时间时，不要只考虑最初写代码所花费的时间，还要加上提升、调整和改进这些代码所需的时间。从短期来看，这似乎是一种损失，然而它带来的却是长期收获。