起源
   　对于电信行业而言，这是一个沸腾的岁月——VOIP、小灵通、宽带上网、短消息、预付费等等业务，一股脑的推到百姓面前，让“上帝”们顿时感觉眼花缭乱；而我们，作为电信运营支撑系统（主要功能是计费、营帐）的开发公司，也终于有了用武之地。
　　面对忽然出现的市场需求，我们迅速做出了本能的反应：尽我们所能满足电信局用户的要求，抢占运营支撑系统的市场份额。本来我们已经拥有了一个针对市级电信客户的小型计费系统，经过不断维护增强而相当成熟；面对一下子冒出来的不同运营商在长话、市话、IP电话计费营帐以及相互之间结算的系统需求，我们将开发人员分成不同的项目组，在原有基础上分别为不同的客户进行定制开发，并全权负责系统的集成和交付。随着所交付应用的系统数量不断增加，成功的喜悦被一种焦虑和疲惫所代替——客户需求增加/变更和产品缺陷处理。项目团队成员像救火队一样奔赴现场，解决客户的问题。我们就像《人月神话》的描述一样，表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，我们的行动就会变得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质，一个接一个淹没在了焦油坑中。
　　尽管大家鲜有机会当面交流，但是仍然会通过邮件交流一下现场解决问题的进度和方式：我们发现很多用户的需求是相同或是类似的，由于原有系统缺乏该功能，我们不得不针对不同用户去重复开发相同的特性，我们甚至私下提供代码以相互参考。我们有时隐隐觉得该作些什么使开发效率提高一些，但是这种念头在现场用户焦灼而严厉的目光下转瞬间就消失了。
　　公司总部也发现了这个问题，为我们空投了一位技术总监。其实我们对他并不陌生，他曾经在硬件和嵌入式系统的项目中从事过管理工作，一个认为系统开发都是类似的、拥有莫名优越感的项目经理。从他参加了一系列昂贵的培训经历来看，总部仿佛期望将他培养成未来的管理明星，而我们这里就好比这位明星的起跳板和出场秀。
　　刚刚上任，他就为大家宣灌了“平台化”开发的重要意义和方法，声称要将系统开发的像KFC配餐一样方便快捷。他要求项目组把各个系统的特性列出清单，然后将这些特性汇总为一张总表，又加上了一些颇为时尚的定语：跨数据库、跨操作系统、三层结构等等。当我们解释跨数据库在技术实现上是多么困难时，得到的答复是你们可以自行开发一个高效的数据库来彻底解决这个麻烦。在饱受现场客户的抱怨后，我们长久以来被压抑的情绪终于在这种无知和傲慢面前得到了发泄：在一次重要的产品规划会议上，我们将异常乐观的里程碑计划、“乱点鸳鸯谱”般的特性分配进行了彻底的否决，甚至将这个梦想中的“平台产品”戏称为“杀死你三千”（周星驰的一部电影中将各种炸药放在一个篮子里，声称是精心研制出的超级武器，实际上却是派不上用场的废物）。那位曾经踌躇滿志的技术总监在“千夫所指”下黯然离去。