两个程序员的故事

从前,有两家互不知晓的公司,一家叫做“自动会计应用协会”,另外一家叫做“统一计算资本公司”。他们同时决定开发一种提供相同功能的程序。

“自动”雇佣了一位分析程序员,艾伦,来解决这个问题。

而“统一”决定试一下新来的初级程序员查尔斯,看看他是否有真本事。

艾伦做过一些复杂项目,有着丰富的经验,决定采用PQR结构化方法来开发这个程序。于是他找到部门经理,要求增派3名程序员组成一个项目小组。这个小组于是开始工作,捣鼓出初步的项目分析报告。

“统一”这边,查尔斯抽了点时间想了一下需要解决的问题。同事们常常看到查尔斯把脚翘在办公桌上喝咖啡。偶尔见到他坐在电脑前,但是那有节奏的键盘声告诉别人他其实在玩小蜜蜂。

不久,“自动”的小组开始编写代码了。程序员们一半的时间用来编写编译代码,另一半的时间待在会议室里,讨论模块间的接口设计。

查尔斯的同事发现他终于不再玩小蜜蜂,而是一半的时间把脚翘到办公桌上喝咖啡,另一半时间在纸片上涂写着什么。他好像不是在纸上玩“井字过三关”,但看起来不像是在写有用的东西。

两个月过去了。“自动”的小组终于发布了项目时间表。计划再过两个月,他们就会发布程序的测试版本。然后再经过两个月的测试和改进,就可以发布完成版了。

此刻,对于查尔斯的游手好闲,他的经理再也看不下去了,他决定批评查尔斯一下。但当经理走进查尔斯的办公室时,他却惊讶地发现查尔斯在电脑前正埋头写代码。于是他决定把批评先放一放,随便跟查尔斯聊了一下就离开了。然而从此他更加注意观察查尔斯的表现,想借机批评查尔斯。不过不愉快的对话并没有发生,他很高兴地发现查尔斯一直在写代码。人们偶尔发现查尔斯推迟了午餐,且一周还主动加2、3次班。

第三个月的月底,查尔斯宣布他已经完成了这个项目。他提交了500行的程序。程序清晰可读,测试中符合所有的功能要求,甚至具备了一些更加便利的功能,极大地提高了程序的易用性。测试后,程序除了有一处疏忽外,表现得非常好。

“自动”的项目小组到此时已经将4个主要模块中的2个开发出来了。在这些模块被测试的同时,小组继续开发其余的模块。

又过了3周,艾伦宣布提前一周完成了程序的初级版。他提交了一份清单,列举了尚需解决的一些缺陷。测试中,客户发现了一些清单上没有的错误和缺陷。艾伦解释说这是意料之中的,毕竟这只是一个初级的版本,有错误很正常。

又过了两个月,项目小组完成了程序的正式版,包含了2500行代码。测试中发现,这个版本完成绝大部分的最初需求。程序功能上有一两处遗漏,且对于数据输入的格式要求非常严格。但公司最终决定使用这个程序,他们可以训练打字员严格按照要求输入数据。对于那些遗漏的功能,交由维护程序员去添加。

后记:

一开始经理对查尔斯的能力印象深刻。可当他阅读源代码的时候,发现原来问题比自己开始想象的要简单得多。现在看来,这种难度哪怕对于初级程序员来说也明显太低了。

的确,查尔斯平均每天产出了5行代码,这略高于平均水平。但是考虑到项目复杂度是如此的低,略高的生产率也不足为奇。而且经理对他头两个月的游手好闲记忆犹新。

业绩评估中,查尔斯薪水的涨幅大概是同期货币通货膨胀率的一半,他也没被提升。又过了一年,他感到沮丧而离开了“统一”。

“自动”这边,艾伦因为按时完成这个项目而受到表扬。他的主管翻了几页源代码,发现代码符合公司的结构化编程规范。但他很快便放弃了阅读代码的想法,因为它看起来相当深奥。他现在意识到项目的复杂度远比当初自己设想的高,于是他再一次夸赞艾伦的成就。

项目小组平均每人每天写3行代码,刚好是平均水平。但考虑到问题的复杂度,有平均水平就非常不错了。艾伦被大幅加薪,作为奖励,他被提升为系统分析员。

分享这篇文章:
[英文原文:The Parable of the Two Programmers ]

本文的译者:Ryan Chen

Ryan Chen(英文名)。目前在美国圣地亚哥,高通高级工程师。他的微博是@奋斗中的胖胖。你还可以通过邮箱ryanmailing@gmail.com和他进行交流。

25 Responses to 两个程序员的故事

  1. Nicole_Ma 对这篇文章的反应是飘过~
  2. Yiran 对这篇文章的反应是好文
  3. T3_from_wechat says:

    开发大招:写个标志位;先 hard code;上配置文件;先用简单做法;等等。

  4. scott says:

    问题想的简单,做的就少,

    问题想的复杂,工作量就多,而且异常不是那么简单的,

    你能考虑到所有的异常case,已经很不错了

  5. 杨金刚  这篇文章
  6. 杨金刚 says:

    出乎意料

  7. wang says:

    经常能看到的场景—经理的认知能力决定了你的前途。

  8. akan 对这篇文章的反应是赞一个
  9. akan says:

    好文章,这篇文章真是不带明显偏向的典范。
    前一种是牛刀解牛,
    后一种是小刀杀鸡。
    不过最终结果是前者的应用程序被客户认可,可能是因为好的态度挖掘了潜在需求所致。

  10. sky says:

    普通人更在意看得到的,所见所得

  11. 呵呵 对这篇文章的反应是好文
  12. key 对这篇文章的反应是好文
  13. 彤彤 对这篇文章的反应是赞一个
  14. 岳先生 对这篇文章的反应是好文
  15. chpp 对这篇文章的反应是赞一个
  16. luobotang says:

    让人感叹的现状吗?

  17. 大雄 says:

    刚入职一年,还不能体会这种感觉

  18. 金廷莹 对这篇文章的反应是飘过~
  19. 杨文传 对这篇文章的反应是垃圾
  20. 杨文传 says:

    别扯淡了,一个用500行代码能更轻松解决问题,一个用2500行代码都还有那么多bug。只能说明技术总监不合格!!!如果考虑到程序的稳定、效率、扩展性和可维护性以及使用生命周期,简单的代码只能暂时完成功能,却是不可持续的。简单功能可能会有更好的办法,对一个复杂的大项目而言,几乎不会存在这种情况。真不知道写这文章的人是不是开发软件的。

  21. yanheng says:

    查尔斯:千里马(或者赤兔马)
    艾伦:勤劳马
    艾伦手下:一般马
    查尔斯经理:一般马夫A
    艾伦经理:一般马夫B

    ps
    查尔斯想找的经理:伯乐

发表评论

电子邮件地址不会被公开。 必填项已用*标注

壹加壹等于