从前，有两家互不知晓的公司，一家叫做“自动会计应用协会”，另外一家叫做“统一计算资本公司”。他们同时决定开发一种提供相同功能的程序。
“自动”雇佣了一位分析程序员，艾伦，来解决这个问题。
而“统一”决定试一下新来的初级程序员查尔斯，看看他是否有真本事。
艾伦做过一些复杂项目，有着丰富的经验，决定采用PQR结构化方法来开发这个程序。于是他找到部门经理，要求增派3名程序员组成一个项目小组。这个小组于是开始工作，捣鼓出初步的项目分析报告。
“统一”这边，查尔斯抽了点时间想了一下需要解决的问题。同事们常常看到查尔斯把脚翘在办公桌上喝咖啡。偶尔见到他坐在电脑前，但是那有节奏的键盘声告诉别人他其实在玩小蜜蜂。
不久，“自动”的小组开始编写代码了。程序员们一半的时间用来编写编译代码，另一半的时间待在会议室里，讨论模块间的接口设计。
查尔斯的同事发现他终于不再玩小蜜蜂，而是一半的时间把脚翘到办公桌上喝咖啡，另一半时间在纸片上涂写着什么。他好像不是在纸上玩“井字过三关”，但看起来不像是在写有用的东西。
两个月过去了。“自动”的小组终于发布了项目时间表。计划再过两个月，他们就会发布程序的测试版本。然后再经过两个月的测试和改进，就可以发布完成版了。
此刻，对于查尔斯的游手好闲，他的经理再也看不下去了，他决定批评查尔斯一下。但当经理走进查尔斯的办公室时，他却惊讶地发现查尔斯在电脑前正埋头写代码。于是他决定把批评先放一放，随便跟查尔斯聊了一下就离开了。然而从此他更加注意观察查尔斯的表现，想借机批评查尔斯。不过不愉快的对话并没有发生，他很高兴地发现查尔斯一直在写代码。人们偶尔发现查尔斯推迟了午餐，且一周还主动加2、3次班。
第三个月的月底，查尔斯宣布他已经完成了这个项目。他提交了500行的程序。程序清晰可读，测试中符合所有的功能要求，甚至具备了一些更加便利的功能，极大地提高了程序的易用性。测试后，程序除了有一处疏忽外，表现得非常好。
“自动”的项目小组到此时已经将4个主要模块中的2个开发出来了。在这些模块被测试的同时，小组继续开发其余的模块。
又过了3周，艾伦宣布提前一周完成了程序的初级版。他提交了一份清单，列举了尚需解决的一些缺陷。测试中，客户发现了一些清单上没有的错误和缺陷。艾伦解释说这是意料之中的，毕竟这只是一个初级的版本，有错误很正常。
又过了两个月，项目小组完成了程序的正式版，包含了2500行代码。测试中发现，这个版本完成绝大部分的最初需求。程序功能上有一两处遗漏，且对于数据输入的格式要求非常严格。但公司最终决定使用这个程序，他们可以训练打字员严格按照要求输入数据。对于那些遗漏的功能，交由维护程序员去添加。
后记：
一开始经理对查尔斯的能力印象深刻。可当他阅读源代码的时候，发现原来问题比自己开始想象的要简单得多。现在看来，这种难度哪怕对于初级程序员来说也明显太低了。
的确，查尔斯平均每天产出了5行代码，这略高于平均水平。但是考虑到项目复杂度是如此的低，略高的生产率也不足为奇。而且经理对他头两个月的游手好闲记忆犹新。
业绩评估中，查尔斯薪水的涨幅大概是同期货币通货膨胀率的一半，他也没被提升。又过了一年，他感到沮丧而离开了“统一”。
“自动”这边，艾伦因为按时完成这个项目而受到表扬。他的主管翻了几页源代码，发现代码符合公司的结构化编程规范。但他很快便放弃了阅读代码的想法，因为它看起来相当深奥。他现在意识到项目的复杂度远比当初自己设想的高，于是他再一次夸赞艾伦的成就。
项目小组平均每人每天写3行代码，刚好是平均水平。但考虑到问题的复杂度，有平均水平就非常不错了。艾伦被大幅加薪，作为奖励，他被提升为系统分析员。
来源：51CTO
