软件也可以这样分，用户可以分成一个个具体的用户，软件公司可以分成一个个具体的开发人员，软件可以分成一个个具体的功能。在这里，每个用户要用到的功能都不是自己开发的，而每个开发人员开发的功能又不是自己用的，这样，在开发人员心目中和用户心目的功能可能是完全不同的两个功能。这里的问题就在于：用户要用的功能（喜欢的菜）是别人做的，而且还不合用（不好吃），但用户又不能不用（不能不吃）。而从开发人员的角度上来说，就是在开发一个自己不用的功能（做一道自己不喜欢吃的菜）。
正因为有这样的根本矛盾，Alexander的“自治”理想在软件开发中并不能很好地实现。
但即便如此，采用管理建筑工地的管理方法同样是不可行的，虽然这种方法在一定程度上是有效的。但不管是在软件业还是建筑业，它都仅限于在“一定程度”上。
当年有一个时髦词语--“深圳速度”，后来却不再提了，因为它跟更早以前的“亩产万斤”有异曲同工之妙。当年人们幻想通过无限制地减小庄稼的株距和增加施肥量来增加单产，结果却是千里饿殍。后来的人们幻想通过没日没夜地加班加点，无限制地缩短工程各阶段的时间来加快进度，然而结果却留下质量隐患。
软件业也一样，偶尔对开发人员加压可以达到在一定程度上加快进度的目的，然而它会有很多问题：
首先，这种方法很快会失效，员工的工作时间越来越长，效率却直线下降，因为体力劳动与脑力劳动有本质的区别，大脑远比身体要容易疲劳；
其次，与建筑业一样，这同样会带来很多质量隐患，大脑在疲劳时犯的错误要远远高于平时，不论是对于开发还是测试；
最后，这种方法是严重的副作用，就是人员流动，最坏的情况是整个TEAM的人都受不了，全跳槽了。在建筑业这不是大问题，建筑工人多的是，换一拨就是了。当然，现在程序员也多的是，但问题在于换一拨是绝对行不通的。
