语言只是工具。第一次正视“软件工程”这四个字。我第一次看清楚代码、方法、过程、工程与组织的关系！你看不到你做事的行为，也就不能理解“模式”作为一种方法的价值。模式需要一定的编程经验才能理解。经验来源于回顾、理解与分析，而不是你将要写的下一行代码。从这个模型中可以看到，在“程序”与“方法”层面，是关注于“（具体的）实现”的；而在“过程”和“工程”层面，更首要考虑的是团队问题。从角色的角度上来说：开发经理思考项目的实施方案和管理具体的开发行为；而项目经理则保障团队的稳定性和一致性。过程伴生工程而出现。过程解决的是工程中角色间的关系问题。因此过程中的问题，就是角色、沟通和环节的问题。软件工程的体系中，“实现”作为软件开发的本质需求和基本动因，如同上帝之手在推动这几十年来的软件工程理论体系的形成。
“牛粪图”中描述的工具、方法与过程也被称为软件工程的三个要素。在本书中他们被分解开来思考，并不是要孤立这三个层面--他们实际上是相互作用的。在工程中使用UML图，应该有相应的文字来描述它。而且这种描述与图之间的对应关系要持续地维护下去。如果这种关系松散了、断裂了，那么下一个阅读UML图的人所面对的，将是无异于甲骨文出土时的困境。在项目的平衡三角（时间、资源和功能）中讨论的是目标问题，但并不讨论质量问题。刚才说到目标与质量的问题时，提及“平衡时间、资源和功能三者的关系”。这其实是一个实施过程中的细节。或者说，它是一个具体的方法，而不是目的。“未蕴而变，自欺也。知律而变，智者之道也”，实为良言。“知律”的另一层意思，是在于“知道原理”。明白“为什么要这样”或者“为什么不是那样”。这在软件开发中是常见的问题，大多数人不知就里地使用着技巧和方法，而一旦出了问题，则归咎于这些技巧和方法的不好。而真正的问题在于，这些人（我们通常叫做Copy&Clear）并不知道这些技巧，技术和方法的原理，因而不知道变通，也不知道回避错误。有时确实是这样，比如我可能会简单地使用多媒体定时器，但是上次关闭定时器引起程序崩溃的问题，我就抱怨是多媒体定时器没设计好，实际上我知道，应该是我没使用对，为什么没使用对呢，那就是我对其原理理解不够。但是，有时我们确实没有那么多时间去研究透一个东西，我们该如何选择呢？