——关于个人OR整体，少数人才OR多数普通人
让我耳目一新的观点是增加人数反而会使效率降低。这个主要来源于两个方面，一是新来的人无论多么厉害，都需要原有队伍里的人去花费精力培训，这时这个人的劳动力就暂时配排除在外了，放眼整个开发周期，除非时间还很长很长，否则是不划算的（但时间很长很长的话，谁会考虑去加人呢）。另一方面是人与人需要沟通，人越多，沟通就越多，且非线性增长，工作量按照n(n-1)/2递增，甚至抵消了对原有任务的分解。这就是为什么增加人数反而会使效率降低。
书中给出的例子是：着火了用油去浇灭，火更大，浇更多的油的恶性循环。越到后期加人所带来的负面影响就越大于正面效果，所以工程后期完不成，按需加人的方法是行不通的（时间允许的话，如果加人，算上培训所花费的人月）。你只能选择等或者吃生的煎蛋。这时需要项目经理进行合理的安排，是消减程序还是安排人手。
若是对于一个刚开始就很庞大的一个团队，比如1000人，如何协调关系，共同完成任务，我看到这个题目就头大了。1000个人，光是分组就是个问题，如何使所有人直到自己的任务，领导又能知道所有人的进度，真是个巨大的难题。书中提出了外科手术式的关系协调。不同地人做不同地事，且统一听从安排。要保证系统的完整性，那么负责分配任务的少数一两人是了解完整的系统的，胸有成竹！而不是一窝蜂的上各做各的，那样一个系统会变得四分五裂，不但进度缓慢，对于使用也会带来的困难。而一个程序的最终目的就是为用户带来良好的使用体验。
确保系统的完整型还涉及到一个问题，负责设计的人可能有很好的创造性，但是被统治的普通人保不准也会有灵机一动的点子，甚至是更好的点子。凭什么这一部分人就只能被统治，不能发挥自己的创意。听起来似乎很有道理，但是这会带来混乱，之前所说的系统的统一性就难以保证。既然你有很好的点子，但你又不是项目负责人，那说明你不够厉害，当你足够厉害，统领一方的时候，自然能发挥你的创造。
而且完整的，确定的方向对于程序员更好的去发挥是很重要的，这使得程序员能够专注地去做本应该做的事。
外科大夫式地协调也使得各有分工，不同地人去做各自擅长地事，这样才能有效率地写出一个系统，车库里编出来地程序只能事一个点子，延伸出去变为系统，是需要一个团队地努力地。（当然你也可以花费几年或更久，但那就过时了。）
但如果是一个没那么大的东西，少数的精英不一群人更有用，你不用面对一堆人头疼，也可以用相同的成本创造更大的利润。