三、RAD之死与系统的复杂性
RAD在较小规模应用的开发上，具有相当的优势。同时，它具有两方面特性：
- 对于应付在各个模向分层上需求相对均势，并且在开发工具商提供的方案可应付的区间内的需求中，RAD以及使用RAD开发的团队具有极大的能量。例如早期的C/S模式下的数据库应用。
- 对于系统可以纵向切分（为多个子项目或独立模块），而且各个部分满足上述第一项的特性时，RAD在应付这类系统的规模增长上也具有极大的能量。例如群件、或中间件等。
对于上述两个特性之外的系统，RAD的团队难于组织、管理，也难于复制。显然，RAD对个体特性的要求过高，不利于团队的成长。大公司的高人们，难道真的没有看到这一点么？
不是，他们看到了。VS.NET开始把产品做成产品线，发布开发产品的不同版本：设计师的、架构师的、测试工程师的……等等这些。与此相同的，各家都开始这样切分产品。但是相同的产品线名称迷茫了开发人员：大多数时候，我们要么选用不分这种版本的早期产品，要么选用这种产品的最完整版本。而后者，正是大公司的销售经理最喜闻乐见的，他们会相互吹嘘自己买出去多少个Site Suite版本，并同时拿Web Devleper版本的业绩来开涮。同时，大产商也不会无视市场的价格而鼓吹单一版本，因为那样的结果是：“网页制作应该用macromedia的”、“图形设计应该用adobe的”、“数据库得选Oracle的”、“服务器最好用Linux便宜”……
拆开来买的“大”产品，虽然不至于一文不值，但至少没大产品值价。这个与传统产品不同，其根源在于开发工具的“大”产品没几家做得出来，而“精”却很多人能做得到。大公司可不会为了理论上的正确性而无视于市场盈利。
所以大厂商对RAD工具的细分其实只是假象，用来说明他们的工具足够牛足够大和足够好的一个旁证。这些“细分”的背后是极强的相互依赖性，结果是：整个解决方案还是一家独大。
我认为，系统的复杂性需要横向的切分来分解。因为横向的切分产生的是领域，与之对应的，就是不同领域、产业的力量，而非某个个人或团队或公司的力量。不同领域、产业带来的，是整体性的推动，而不是某个个体的畸形发展。同样的，他也带来了个体品质的提升，例如有了最好的砖瓦匠和水电工，也带来了在更高分层上独立思考的可能性，例如建筑师与城市规划设计师。
当然，我相信很多人认为自己拎上一把锤头就可以做水电工——我前两天在CSDN论坛里就看到了这样的观点，我也相信很多人认为建筑师与城市规划设计师都是饭桶，他们存在的目的仅仅是就业安置或者消耗粮食。我完全相信这种观点的存在，但不同意它。我曾经做过电工，我知道用一把锤头敲击就听出设备的好坏是需要10年以上的功夫的；我也知道如果没有规划师，城市会比现在更乱而不是更好。
你可以批评别人做得不够好，但把你放在相同的位置上，你未必做得更好。这与横向分层理论带来的效果是一样的，你可以认为自己能做好所有层次上的工作，但你真要去做的时候，却未必做得到。以及，由于你——这个个体不能被拆分，所以你的工作是串行的、效率是有限的，结论正是：在这样的思想下，大的系统会越做越糟糕。
横向分层带来的结果要变成良性的，就必然是相信每个层面上有相“匹配”的人员。你要信任它，并主动合作，你要相信团队是一个多层结构，相信团队中的其它人会给你帮助，以及需要你的帮助。你做不到一切，你依赖于别人而达到你的成功。
同样的，你也必须认识到：没有任何一个团队一开始就是这样的。团队需要清理，需要沉淀。需要花费一些成本来建立沟通，并逐渐形成合作的模式、默契。当然，另一种更加不错的方式是：整个教育和培训行业相信这一点，在程序员走向商业产品开发之前就培养他们的团队组织与协作能力，从习惯于服从和配合，到学会观察与学习，以及在团队中如何自我提升。等等这些，才是我们传统行业——例如我们常常提及到的建筑行业中的职业进化模式。
产业的、领域的推动才会解决系统复杂性的问题，而不是某一个或几个大公司在他们各自有限的领域中折腾。他们折腾的目的、根本只是为了商业利益，而不是为了解决问题。
