程序是对数据流的处理，从这个角度来说，算法是程序的灵魂，特别是在搜索，语音识别等领域。但随着程序规模越写越大，我们发现我们的程序越来越难维护，于是出现了改进的编程语言，设计模式，软件工程等从技术和管理角度改进的方案。我们照做了，如果做的好，我们看会到我们的程序越来越健壮，程序几乎不需要增加更多的成本就可以一份一份的拷贝卖给更多的客户，于是一幅美好的蓝图展现在我们面前。当然这只是一个假设，实际实施过程中因为各种各样的原因，甚至无法将过程完成。 一个针对特定需求开发的应用软件开发完成后，很多情况下确实能满足绝大多数客户的需求。根据80-20原则，我们可以根据实际情况考虑是否一定要剩下20%的客户，毕竟我们要的是实现利益最大化。
然而，在我这几年在平台项目的开发过程中，我发现，平台软件和应用软件有很大的不同。首先，平台软件是针对特定领域而不是针对特定应用开发的，这就决定了你开发的软件不能是一套单纯的软件，而是一些软件开发的基础设施，有了这些设施，我们可以方便的开发出这一领域，甚至交叉领域的应用软件，这要求你的基础设施要是细粒度的，相对通用的。为了开发方便，在开发接口上，要很好的体现出对象逻辑结构，层次结构。其次，平台软件是应用模糊的，同样的一个输入，根据应用的不同，产生的输出是迥异的，这是我们无法完全预测的。你的东西要是可以订制的，可灵活配置的，对于一个固定输入输出的东西还能叫一个平台吗。配置太麻烦也不行，不能动辄要求开发人员来订制。不能要求二次开发人员对你的东西要有深的了解，他只关心的是自己业务。比较好的做法是只有必要的时候才打开一个缺口。在STL中，我们就能获得很多启示，每个concept，iterator，container，algorithm,没有那个东西是死的，虽然是很简单的几个东西，组织起来的威力让人叹为观止.而在其中可以加入自己的东西却又能很好的融合.
从这两个角度来说,平台软件的团队里必须有精通该领域的人,在他的眼里,只要是该领域的需求(当然是理论上可以解决的问题),都能迅速转化为一个可实施的模型.他胸中有"大略",所以能进行高层的抽象,作的东西才有普适性.同时,东西要转化成解决方案,靠的却是开发人员.开发人员能理解模型的深层意思吗,我看很多情况下未必;即便开发人员理解了,他能把它转化成良好的软硬件模型吗？同样是困难重重！根据我这几年的看到的东西,我认为我们没有那个环节做好了,可能这也是国内的大气候,大家都很浮躁,没有人从深层次思考这些问题,因为大家都在向"前"看.虽然实际可能就看见前面三尺.
那些自以为很强的人或公司，其实未必有能力实现自己的目标，很多情况下是高估了自己的实力（包括技术水平，企业文化，创超力等）。虽然能做好很多项目，但在开始平台开发项目之前一定要三思而行。