第四章的标题“乐高王国”描绘了程序员心中一个美好的梦想：做软件就像拼装积木一样，事先将各种小的组件做好并制定全球统一的规范接口，程序员只需在零件仓库里找出相应的零件按需拼装。
这个梦想听起来如此完美。如果每个软件组件都像乐高积木那样标准、可靠、可复用，软件工程将从编程的窠臼中解放出来，开发效率将得到质的飞跃。然而，现实远没有这么简单。
书中揭示了一个深刻的悖论：程序员们一再发现，几乎总能找到一段满足大部分需要的代码，但这些拿来的代码所不能做到的部分，恰恰是项目与众不同的创新之处——也是创建这个项目的出发点。换句话说，通用组件解决了80%的常规问题，但真正让一个项目有价值的那20%的创新，恰恰无法通过复用现成组件来实现。
更棘手的是组件间的兼容性问题。当多个来自不同来源的组件被组合在一起时，它们之间的接口可能不匹配，文档可能不清晰，甚至各自依赖的底层库可能相互冲突。Chandler的后台工作就陷入了这样的迷宫——系统架构师安德森一个人就要面对一系列艰难抉择：应该用什么工具来创建图形界面？应该用什么技术来存储数据？应该采用哪种数据交换标准？
在osaf开发组中，负责选择其他程序员用来创建软件部件的“系统架构师”安德森一人就要面临一个又一个难以抉择的局面，这让我真切地感受到软件是多么的抽象。
这一章还让我思考了“牛仔程序员”的问题。在追求模块化、组件化的同时，我们不能忽视一个基本事实：软件终究是由人写出来的。再好的组件、再完美的架构，如果编写代码的人缺乏责任感和工程素养，项目仍然会走向失败。软件工程不仅仅是技术问题，更是一个关于人的问题。