多年以前,如果我像现在这样了解做软件难过蜀道,那我说什么也不敢接那个上青天一般的苦活儿。那时候,我作为某公司CTO,带着一队人马进驻河南郑州,租一辆破旧的面包车,每天往来于客户办公室和五室二厅的出租屋,兴致勃勃地开始软件开发。

那是一套类ERP的大型软件,需要支撑客户的核心业务。想来好简单,老板一拍胸脯:100天交付!可是100天一眨眼就过去了,选择“时尚的”J2EE技术路线的我们,既没摸清客户的业务需求,又没掌握那个“看起来很美”的爪娃。

话说,甲方在签约之前是上帝,签约之后就变成了孙子。我们也不想逼客户当孙子啊,可是我们也没办法,软件开发这东西,就像瓶子里的魔鬼,只要拧开瓶盖,一切苦难便开始了。

就在上周,我们的一个软件项目终于完成终验。历时一年,沟沟坎坎无数。现在我已经身在另一家公司,也不曾从事具体的项目开发,只不过它是我之前IT规划项目的一个延伸。可是仍然让人感慨万端:这出世的“娃娃”,跟规划中的模样究竟有几分相像呢?于是就在终验晚餐现场,有人喝多了,有人流泪了。

“你越懂软件,就越不会去做软件。”卡普尔说。这位曾经的OSAF主席,投入数百万美元、数十名软件高手、数年光阴,只落得Chandler废墟一座,即算再理想主义、再梦想令人激动的杀手PIM套件,又怎能不心生唏嘘,把指点江山的壮怀激烈化作一句悲叹!他如果是中国人,一定会像陶渊明一样吟颂“归去来兮”,然后从OSAF挂靴而去,再不管什么Chandler,再不管什么软件开发。

《梦断代码》以Chandler为线索,穿梭出软件之梦、代码之断。软件之梦,断断续续几代人;我读这本书,断断续续数十日;我写这篇blog,也是时写时停近一月。悲夫!为什么软件之梦那么难圆,甚至连有关软件梦想的书都那么不忍卒读呢?

软件之难,在于其软,任何一款软件,你都无法准确描述它长什么样儿;软件之难,在于其软件人,即使是所谓软件蓝领,你也无法像流水线一样去组织他们。以此无形去造彼无形,则何以有形!于是“金三角”的每个方面都无法保证,于是超出预算、延期交付的软件,已经算是非常成功的了。

软件之难,其实难在用户。以软件产品之无形,弥合用户需求之无形,则何以有形!于是用户只能和血吞牙,纵然死亡的软件尸骨遍野,你也很少见到什么人宣布他的失败。

软件究竟是工程还是艺术?这个问题似乎早就不存在。依靠工程方法,把软件打造为产品,满足各行各业的IT需求,并且从中牟利到世界首富,早已是板上钉钉的事实。软件,或者说做软件,当然是工程。

可是又不得不承认,貌似高科技的软件,戴上“IT民工”的工程帽之后,却常常尸横遍野,就连用户,固然不上软件是等死,而上软件却成了找死。软件的工程方法,是现实,但软件工程之殇,却也是事实。

软件作为智慧产品,像就作家写书,当然是人数很少的团队来干比较完美和精致,就像古老的Unix和尚属时尚的Linux,至少基础是一两人奠定的。可是只有在不受时间和费用限制的前提下,由大师手工精雕细刻出绝世精品才成为可能。

于是有《人月神话》,于是有教堂与集市,但是很不幸地,仍然还有《梦断代码》。呜呼,当真是软件难做、软件人难做、软件梦更加难追吗?

也许,软件介乎工程与艺术之间。如果一定要比拟的话,我觉得与做软件最像的,是做电影。电影也可以按纯工程方法泡制出商业巨制,也可以按作坊方法鼓捣出小众艺术,但无论是哪种,每部电影都是由分工协作的小团队制造出来的,永远见不到传统的万人大工厂。

其实软件也是这样。CMM似乎成为工程之标准,而软件巨人却按自己的模式玩,像微软就是按照自己的MSF,而MSF是以团队模型为基础的。据传曾经红火的湖南创智创始人丁亮到美国看了微软的软件开发,便不敢再做软件了,可是他后来的服务转型似乎更失败——这没有什么可奇怪的,即使是他的榜样也不能总是成功啊!

多年前承诺百日交付的行业软件,后来通过另一个团队的进驻来解决。这帮家伙在那个行业浸洇多年,对行业特征十分掌握,采用的开发工具是当时已遭淘汰的PowerBuilder,但是他们确确实实救了我,救了那个公司。然而事隔多年之后,这伙软件人的境遇怎样呢?不言自明。

但我还是不愿意承认梦断代码。软件可以失败,软件人可以落魄,但是人不能没有梦想。毕竟,我们还是有机会通过客户的终验,用IT手段支撑起客户的业务——即使涕泗滂沱,我们也要相信阳光、相信彩虹。