没有救世主
没有救世主，这是国际歌里唱到的。也是我党我国一直奉行的基本原则之一。
在软件项目开发中，该基本原则也同样适用。有关该原则最著名事物就是《No Silver Bullet — Essence and Accidents of Software Engineering》这篇上世纪80年代出现的饱受争议的论文。在英文中间银弹和我们这里的救世主按我的理解是同样的意思。
我们常常听说某种开发方式，某种工具能够大大的提高生产效率。但是实际上，结果常常让我们失望。即使向RoR和Visual Basic、Delphi之类的东西的出现在某些方面的确解放了部分生产力，但是对于较为复杂的软件项目，这些技术都有其局限性，而这些技术的learning curve也是存在的，又必将大大降低生产效率。
曾经有项统计说1991年利用面对对象技术而达到生产效率提高的项目为91%，而两年之后降低为66%（记得个大概）。原因是最早使用OO的人都可以称的上专家，他们对传统设计方法的优缺点了如指掌，从而可以在传统设计不足的地方导入OO，而在OO不足的地方继续使用原有的设计方式，从而达到最佳的效果。但是后续的人员都是跟风之徒，跟风的人不仅从技术上而且从觉悟上都是比先驱差一个level的。因此，生产率没有得到提升是很正常的。
具体的例子是Java。很多人鼓吹这玩意好，没有memeory leak，编程模型简单。结果缔造了60%的项目失败率（bitter java上云）。谁说没有内存泄漏的？《bitter java》告诉你java上如何产生内存泄漏。
之前曾听一个搞java的人说过这样一个故事，他们做了个系统，年维护费用3000w日元。但是出个问题是每天服务器必须重启，不然就死在那里了。所以他们找了三个人在现场轮流值班，每个人花费是每年600w日元。剩下公司的日常开销，营业开销，基本上这个项目的维护费就没有盈利。原因？查不出来。其实不是查不出来，而是查出来太难，需要对源代码中的循环引用进行分析，找出memeory leak的位置。在源代码数量巨大的情况下，工作量没办法用维护费用填补，只好等下一个版本的时候抹平这件事情。
所以不要指望新技术能给你带来质的变更，尤其是那些沉迷于摆弄新技术的开发人员。在思维不清晰的情况下，其实是被新技术摆弄。
开发人员热爱新技术，这可以给他的简历加分。作为管理人员要避免这种倾向，实际上软件的核心在于理解要做什么和清晰地表达如何做。这正是为什么有些项目的生命周期长达2，30年的本质所在，尽管这些项目用的是传统的瀑布模型和老掉牙的cobol。
