引言
“如何面对低能力程序员？ 这个话题看起来是说只有最好的程序员才能同时“设计”与“编码”。 之所以有如上那些中间设计步骤与那些提到的工具，是为了弥补一般程序员的经验、能力不足。
在我看来，这就象问“一个医生没有能力，我们该怎么办？” 我知道医学与软件开发并不相似，但请容忍一下。 大量的医学实践基本上是死记硬背。 然而，医学专业在一个人可以被称作MD之前，在智力、教育与经验方面坚持相当高的选拔标准。 换句话说，我们希望我们的医生能清楚地知道他们在做什么。
软件开发中，低能程序员的问题在演变成用过程来替代智力、天赋与经验。 很明显许多人在想只要我们强行要求人们画足够的UML图（或其他什么玩艺），做足够的检视，遵循一个详细的过程，最后他们就能弄懂他们在做什么，并且能正确地编码。 这种方法在过去没有成功过，我也没看到任何理由可以相信这种方法在未来会成功。 实际上，根据我自己的经验，要用好象UML之类的工具，需要相当水平的专门知识与经验。”
讨论
软件本质上是精英游戏，但是全社会的娱乐化对它提出挑战性的要求－－快速开发。快速发展，快速消费的冰淇淋式的娱乐化，把旅游变成“上车睡觉，下车撒尿，回来一问，什么也不知道，只有看照片，不同的人在傻笑。”如果问题软件项目经理，你最想要什么资源，多半是时间，而不是高水平的开发人员。而没有时间的问题，习惯上通过增加人员来解决，《人月神话》30年前提出的问题，现在更加严重。
从统计学来说，经理不可能找到足够多的优秀开发人员。因此要找到足够数量的人，只能把及格线下降。40年前要到博士才可能写代码，而现在只要初中生就可以了。正如上面提到的，我们不断尝试通过过程来保证更差的人能写出更好的软件。从结果来看，这个努力卓有成效。但是对于娱乐化的浪潮来说，这只能产生更大浪头。
因此，我们不应讨论软件开发需要什么样的能力，而应讨论如何才能用更差的人来交付刚好满足需求的软件。而且这个更差，是相对的。只有更差，没有最差。
软件产业大量从高学历，高人力成本的欧美地区转移到教育程度不高，人力成本的东欧，亚洲地区从一个侧面反映了这个进程。
敏捷过程正是一个解决方案，虽然它还需要一定的能力，不能太差。事实上它的能力要求还高于软件作坊对开发人员的能力要求，但它大大提高了交付刚好满足需求的软件的可能性。
这个进程也促进了软件人员的分化，30年前很少有没有高级软件工程师，而近十年架构师成为每个初级程序员的梦想。软件工程师很自然的从一个高端职业变成了数个不同层次的职位。
今天，一般的应用软件开发已经进入搭积木时代：一个全功能的交友网站或购物网站，报价只有6000人民币，而十年前报价是它的100倍。老牌的软件公司则向价值链的前端移动，以留出更多的空间，让更多的小企业进入这个价值链的最末端。如微软、Oracle开发工具和平台；IBM则更进一步到建模和业务分析领域。Tencent和奇虎则是末端价值链的代表，这种地位注定了它们的竞争是血淋淋的。
通信行业做为国家命脉的特殊性，与银行业一样，在技术进步上相对保守。大多数企业还在以CMM（如N）或原始的敏捷（如E///）方式做软件，相应的人员水平也较高。但后进者已经面对新的挑战了：我们有近10万开发人员，将来会更多，不太可能保持较高选拨的水平，如何让他们交付用户需要的软件。
其实答案已经非常明白，我们有大量搭积木的人，而他们没有积木可搭。许多项目组要做的东西连图纸都还没有，而成员大多只有一两年开发工作经验－－并不足以从打铁开始建造艾菲尔。从这个角度，我想有两方面的能力需要建设，如何源源不断的产生“更简单的”积木和如何搭积木。
我们在减少管理层次的同时，要打造另一个层次－－技术层次，甚至对接到通用软件的技术层次中去。一
个很好的参考是：开源软件中有很多应用被反复构造，从本质而言正是不同技术层次的较量。同样的Emacs架构，可以分别通过Emacs和XEmacs以及众多的仿制项目组实现。同样的需求衍生出了众多架构，技术，实现，仿佛一个金字塔。Eclipse也有类似的情况，甚至Windows也有Wine和ReactOS这样的仿制品。这些架构，技术，实现层面的探索，产生了大量的积木。打开QQ、金山词霸等等常用软件的目录看一看，他们用了多少积木。
当我们还没有更简单的积木时，不得不用一些复杂的积木，来手造一些自己的积木。首先不要有太高的期望，其次要做好知识管理：以前有人发过一个“搜、问、订”是一个很好的思路，最后还是要面对现实，高水平的积木，需要高水平的人。让高水平的人做一些低于他水平的事情才能产生简单的积木。
永远不会缺少劳动者，总是缺少思考者。