本文翻译自 http://www.csd.uwo.ca/~magi/personal/hum...
曾经有一段时间， 由于不知道彼此的存在，"Automated Accounting
Applications Association" 和 "Consolidated Computerized Capital Corpora-
tion" 决定他们需要一套相同的程序来执行特定的服务。
Automated 雇佣了一名程序员分析师， Alan，来解决他们的问题。
与此同时， Consolidated 决定让一位新雇佣的入门级程序员，Charles，来接手这个工作，看他是否如他自己吹得那样好。
Alan， 曾多次参与困难的编程项目，决定使用 PQR 结构化设计方法。 考虑到这一点，他向部门主管申请分配另外3个程序员组成一个编程团队。然后团队开始工作，产出初步报告和问题分析。
回过头看 Consolidated，Charles 花了一些时间来思考这个问题。他的同事发现， Charles 经常坐着喝咖啡，并把脚放在桌子上。 他会偶尔看下电脑终端，不过他附近的办公室同事能够从那敲键盘的节奏分辨出他实际上是在玩 Space Invaders 。
现在， Automated 的团队已着手编写代码。程序员们花费近一半的时间编写和编译代码，其余时间则在开会 ，讨论许多模块间的接口。
他的办公室同事发现 Charles 最终还是放弃了 Space Invaders。现在，他把脚放在桌子上喝咖啡，或者在小纸片上涂涂画画，以此消磨时间。他的涂画看起来不像是随意的圈圈叉叉，不过似乎也没有多大意义。
两个月过去了。在 Automated 的团队最终出了一个实施日程表。 在接下来的两个月他们会完成一个测试版本的程序。然后经过两个月的测试和迭代产出一个完成版本。
Charles 的主管不想再看到他偷懒了。他决定和他当面对质。但当他进入 Charles 的办公室，他惊讶得看到 Charles 正忙不迭得敲代码。 他决定推迟对质，于是闲聊了几句就离开了。不过他对 Charles 看得更紧了，一旦机会出现就可以当面对质。然而事情没有朝着一个不愉快的对话发展，他很欣慰的看到 Charles 在大多数时间都很忙，甚至有时候午饭都要推迟，并且一周有2到3天是下班后还待在公司的。
3个月后，Charles 宣布他完成了这个项目。他提交了一个500行的程序。程序来起来写的很干净，测试中它完成了规定（specifications）的所有功能。实际上它还有一些额外的便利功能，能显著提升程序的易用性。程序被拿去测试，除了一个快速纠错检查功能外，表现良好。
Automated 的团队现在已经完成了程序依赖的四个主要模块中的两个 。这些模块现在正在接受测试，同时其他模块已经完成了。
又过了三个礼拜，Alan 宣布初版程序会提前一周准备好。他提供了一份自己发现的缺陷列表。 程序进入测试。不光是这些列出来的问题，用户还发现了一些其他缺陷和不足。对此 Alan 解释道， 对此无需大惊小怪。毕竟这只是一个初级版本，有 bug 是很正常的。
又过了两个月多， 团队完成了程序的生产版本（production version）。它由2500行代码组成。当测试它时，看起来它满足了大部分的原始规范（original specifications）。 它删去了1～2个功能，并且对输入数据的格式要求十分挑剔。然而公司还是决定安装使用这个程序。他们可以培训数据录入人员来严格按照规定的格式输入数据。 这个程序最终移交给一些维护程序员来合并缺失的功能。
续篇：
起初 Charles 的上司对其留下了深刻的印象。但当他阅读了源代码，他觉得这个项目比他原本想象的要简单的多。看起来这并不是一个多大的挑战，甚至对一个初级程序员而言。
Charles 每日平均产出5行代码。这也许比平均水平高一些。然而，考虑到程序的简单性，这样也没啥优秀的。更别提他的上司还记得他偷懒的那两个月。
在他下一次的薪水审核（salary review）中， Charles 所加的薪水大约是当时通货膨胀的一半。他没有得到晋升。 之后大约一年，他灰心意冷，离开了 Consolidated。
在 Automated， Alan 因为项目的如期完成而被称赞。他的上司查看了这个程序。大概浏览了几分钟，他发现 程序遵守了结构化编程的企业标准。他很快放弃了阅读程序； 看起来太深奥了。现在他意识到这个项目比他最初设想的要复杂的多，于是他再次对 Alan 达成的成绩表示祝贺。
Automated 的团队每日平均产出3行代码。这只是平均水平，但是，考虑到程序的复杂性，可以认为很优秀了。 Alan 得到了大幅加薪，并且晋升为系统分析师。
1985年3月20日
本人英语未过四级，若有翻译不当之处，请指正。