你做不做？做什么啊——软件工程（旧文留念）

           曾泛泛地看过本叫《代码大全》的书，其他都没记住，只记得讲到一个类比的问题，即“软件的研发”和哪种人们比较熟知的事务有可比性，以便不熟悉软件研发的人（各级管理层，客户等）能够得到个大致合适概念。很多人都把“软件研发”类比成“房屋的建筑”，我也很同意这个类比。
          在上海有很多在建的高楼大厦，路过那些工地，我常常会想：即便是100万行规模的软件研发，难道就比造一幢10来层的楼难度更大吗？ 虽然也有劣质的楼房，但我武断地认为，豆腐渣的软件系统要比豆腐渣的楼多得多。我常自问这是为什么。

        我不知道，是否有刚入行2年的建筑工去主持厂房的设计建造。 但我知道常有刚入行2年1年甚至几个月的人在担当软件项目的负责人。
        我不知道，是否有心急的建筑商看不得设备的闲置，而在没有设计图纸的情况，就让施工队开始建筑“商务楼DEMO”。 但我常看见，管理精英们看不得资源的闲置，而在无研发设计的情况下，驱动研发团队先做个“商务软件DEMO”出来。
        我不知道，是否常会有客户需要把3年的盖楼工程期，压缩到1年（新闻联播中到是常有）。但我常听到管理人员心急如焚地需要把3个月的研发时间，压缩到1个月。

       昨晚在看《非程式员》第9期， 有“交互设计之父”之称的Alan Cooper的访谈里面有段对话(翻译稿):
         smilemac: 例如市场压力、预算、管理水平等等，这些都可能造成项目时间限制，许 多产品是他们之间相互妥协的结果。
         alancooper: “...市场压力，预算...”，任何的都是管理者掩饰他对程式不了解的借口。
       看似偏激，但我觉得说得是一语中的。现实这东西就是个样子，无论您如何臆想他，或忽视他，现实始终还在那里。而真正要面对现实是很不容易的，因为现实总是残酷的。而比现实更残酷的是，管理层往往都很激情洋溢地盘算着商业计划，他们信奉的是“跳一下才能完成的计划才是好计划”，至于您原来能达到哪里他却并不清楚。而研发人员几乎都是天生的乐观主义者，对于他们来说没有“Mission Impossible”。任务越是困难越含糊不清，越能激发他们克服困难的热情和所谓的创造自由度。这有点象我们这些单身汉在灯光昏暗的酒吧里看到一位线条突兀,衣着似露未露的性感MM，所激发得某种生理反应。而当一个相信电脑能算命的客户+ 激情洋溢的管理人员+ 一个（群）乐观向上的研发人员，基本上大概一幕悲剧的演员就全齐了，然后大家一起想象着项目会自然出落得丽质天成，结果多半是“为什么受伤的总是我"。
抱怨了半天，又要提到软件工程了。现在有这样一种情况，
       每次项目挫折总结的时候，上上下下都会说“这是因为没有执行软件工程的原因”。
这时候“软件工程”就象是个大垃圾袋，任何令人讨厌的东西都能够往里扔。至于什么是软件工程，很多数人只怕只有个模糊的概念。多半自己也分不清“软件工程” 和“幸福生活”之间有什么区别。不少人站出来说：“软件工程就是要把研发中的一切文档化可交流可维护，而不要搞心口相传。” “要出一些什么样的文档呢？” 有不少人沉默了，仍然有一些勇敢的人站出来列出一串文档名列表，或拿出“CMM”或“RUP”的文档模板来。“那怎么才能填写好这些文档，并使这些文档的资料足以做为进一步研发的基石呢？"。“...”一片寂静。角落里有几个声音说到“找个咨询公司来做方案，或找个行业专家”。也许有人有这样的好运气，但对大多数项目来说，这几乎是要老鼠给猫去挂个铃铛,把一个问题偷换成另一个问题。
        为什么一幢幢楼能建起来，而一个个软件项目在泥潭中挣扎下去。我只能说和建筑和其他产业相比，软件研发几乎没有工程。因为在如此短暂产业的时间里，还没有足够多的失败和教训来让大家摸索出一条被广为接受的工程方法来。请注意，总结出一是回事情，被大家知道是一回事，而被大家采纳执行就是完全不同的别的事情了。到幼儿园走一圈，我们可能知道健康的孩子是什么样，但我们却不知道怎么才能生出并养育个健康的孩子来。知道目的地，和知道如何到达目的地，也是完全不同的两件事情，虽然他们之间有关系。说到这里，突然想起那些信誓旦旦要在多久时间里，通过CMM X 级的老总们，即便他们生过孩子，只怕由于工作繁忙也没养过孩子。
       出路何在呢？只有去试验、去试错，土法上马。代价是什么？代价就是痛苦和失败。软件工程方面的试验是困难的。一个人一台机器1、2个小时就能够试出一个 API的使用来,而4、5个人1、2个月也未见得，试出一个工程方法的优劣来。而在一个新软件工程方面的导入在初期，引起研发混乱度的增加也是很常见的，谁也无法确保某个别人行之有效的方法就一定适合您的项目团队。况且，也很少有哪个老板愿意给您个项目试着玩。难归难，日子还要过。有前辈说了：痛苦的经历是改善流程的源动力。
这里我推荐两本书,管不管用就看各人的造化了。
1.《软件需求》机械工业，书很薄，有操作性。薄书就能说清的事，为什么要去看厚书呢?
2.《软件创新之路》电子工业 . 程式写多的人应该看看。想以MS为模仿对象的人也该看看。

也许我们知道未来是怎么样，但不知道怎么样能活到未来。


后话：
1.可能是2002年写的篇东西，很多观点有了变化，只是找个地方挂一下。
2.这些年来，对于软件开发的“隐喻”的思考，又有很多的新发展。“建筑”已经不是最恰当的隐喻了。