程序开发是如何搞砸的？

——关于《梦断代码》的思考

我们所使用的许多大型软件，均以洋人出品为多，这颇给人一种错觉，即外国人在程序开发上无论是效率还是成功率，都大大高于我们国产程序员。妄自菲薄并不是一天炼成的，它有着深厚的“群众基础”，因为在许多我们参与或见识的开发过程中，往往是“眼看他起高楼，眼看他楼塌了”，甚至连“宴宾客”的机会都没有。一个程序（或系统）的开发完成之日，往往就是它的墓碑奠基之时，于是乎，业主恼怒，管理者窝心，程序员头痛，极端一点的，居然“风紧，扯呼”了。

而在这个世界的另一个行业——建筑业——却时刻在上演着一幕幕“精准”的大戏，无论是那828米高的哈利法塔大楼，还是延绵长达几十公里的杭州湾大桥，其设计和施工难度，都远远高于世界上的任何一个软件系统，但是建筑师们却极少会让大楼建到一半倒掉，或是让两个标段的桥面高程相差几米，人家那玩意才配叫“工程”。在建筑业中，“重构”乃是不可思议的任务，搞不好，设计师会坐牢的呢。这真是程序员们的幸运，毕竟无论项目的标的是多少，还从未听说过代码写不好的程序员被判刑的。

话在说回来，根据美国国家标准与技术学会（NIST）的统计，就是老美那边，仅在2002年，软件错误就造成了595亿美元的经济损失，而2/3的项目明显延误或超出预算，甚至干脆就无疾而终了。可是，有一个问题一直在让我们思考，为什么软件项目如此难以搞定呢？为什么脑力劳动的开发工作，可无限重构的虚拟环境和真金白银的投入，最后却换不回应有的回报呢?针对这个问题，作家Scott Rosenberg对一个著名的开源软件Chandler（一款深得GTD精髓的个人信息管理软件，它立志超过Outlook）进行了田野调查，这是一款由米歇尔.卡普尔赞助的开源应用基金会（OSAF）开发的产品，它的开发资本雄厚，卡普尔对OSAF的赞助高达500万美元；它的开发人员都出类拔萃，编写过Macintosh操作系统和Netscape浏览器等不凡软件。但结果呢，“两打程序员，3年时间，4732个bug”，尽管这一项目开发仍然在继续，但从项目管理角度而言，它早已失败了。

这些牛人们是如何搞砸这件一开始让人激动不已的事情的，让我们来看看全书中各种各样的理由：

• 软件开发之初没有蓝图；
• 你所需要的时间取决于别人所花的时间；
• 这个bug是因为我采用了开源代码，除非开源开发者自己来修正代码，否则我们就得绕过问题所在；
• 开发人员之间太民主化了，缺少等级制结构，所有的问题都得让所有的人来讨论；
• 旧的牛人们沮丧出门，新牛人们又鱼贯而入。
• 。。。。。。

够了，这些理由掩盖不住的是，在项目开始后的9个月中，不凡的程序员们每天都在使用何种开发语言，是不是用P2P数据交换结构，以及给各种bug起一个富有神秘意味的“绰号”上下功夫。

讨论，讨论，再讨论，这个项目组除了犯《人月神话》中“往一个落后的系统追加人员只会让系统更加落后”的“悖论”外，无休止的口水战占据了太多的白板，Bugzilla（一款Bug管理软件）上各种各样俏皮的bug严重程度描述术语浪费了太多的时间。在软件项目的开发过程中，每个程序员都认为自己很聪明，聪明到认为别人的思路和想法大错特错，必须让自己给“重构”才合格，这一堆聪明人在一起所干的蠢事，是浪费了7年时间和几百万的金钱。

“他养活Chandler和OSAF达六年之久，寄望于能做出令人激动的创新PIM套件。……六年后，Chandler仍无定形。……（离开的）时候差不多了。”六年半时间，上百万美元，几十号顶尖高手，换来幻梦一场，此时最郁闷的，当属米歇尔.卡普尔。

而在这世界的每一个角落，一项又一项的建筑工程正在拔地而起，几乎不差分毫地指向蓝天。而“编写”这些“建筑代码”的，是普通的建筑工人，他们不需要太聪明的思考，不是吗？！
 

Related Items

• 关于RESTful服务的迷惑

• 推荐两本Dojo的好书

• 学习AO的一些体会

• ZT一个明朝的笑话