Observe that for the programmer, as for the chef, the urgency of the patron（顾客）may govern the scheduled completion of the task, but it cannot govern the actual completion. An omelette（煎鸡蛋）, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices-waits or eats it raw. Software customers have had (1)choices.
Now I do not think software (2) have less inherent courage and firmness than chefs, nor than other engineering managers. But false (3) to match the patron's desired date is much more common in our discipline than elsewhere in engineering. It is very (4)to make a vigorous, plausible, and job risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers.
Clearly two solutions are needed. We need to develop and publicize productivity figures, bug-incidence figures, estimating rules, and so on. The whole profession can only profit from (5)such data. Until estimating is on a sounder basis, individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches are better than wish derived estimates.
空白（3）处应选择（）
A.tasks
B.jobs
C.works
D.scheduling
参考答案：D
解析：对于程序员来说，就如同厨师一样，要急顾客所急，适时提前完成任务，但这并不意味着任务是保质保量地彻底完成了。预定两分钟完成的煎蛋，如果再多给点时间，或许会做得更好。倘若没有两分钟的设定时间，顾客就可以有两种选择：耐心等待吃好蛋，或半生不熟地吃煎蛋。软件客户也有着同样的选择。我不相信软件项目经理的勇气与决心还比不上厨师或工程部经理。然而在我们的学科领域内时常会有对客户不当的时间安排，这比其他工程领域更普遍。经理们经常主要凭直觉而不是通过量化的办法去预测一个软件需要的完成时间，在这过程中几乎不使用任何数据。要想有理有据，合情合理地对此进行辩解实在是一件困难的事情。显然此时需要两个解决方案。不但需要计算，还要公布生产率数据、错误发生率数据、评估规则等。这些数据共享对整个行业带来的只有益处。只有数据基础更可靠，每一位经理才能挺起腰杆，有理有据地对自己的预测进行辩护，同时相信他们的直觉仅仅是希望得到的预测而已。
