一

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

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

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

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

二

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

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

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

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

三

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

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

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

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

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

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

四

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

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