开头给我们举出了一个例子，大公司是如何在软件工程中进行运作。Rational 被 IBM 购并的真实原因在于 IBM 需要构建一个完整的软件工程体系，对于 IBM 来说，Rational 有着 UML 语言的非常丰富的实践经验， 还有着 RUP 作为理论框架的创立者和领导者的地位，这些对 IBM 在确立大型软件工程应用方案提供商的行业形象，都是极大的支持。而另一个开发商：Borland 没有在 ALM 作为工程理论方面的任何优势。于是 Borland 开始购并与实现 ALM 体系相关的公司，其中收购过程改进咨询公司 TeraQuest 并组建流程优化实部，以及收购 TogetherSoft 为开发工具来强化模型构建能力，都是相当大的一些举措。通过这些努力，Borland 快速地补全了 ALM 作为一个工程体系在理论方面的不足。而处于风口浪尖的Microsoft 与 Borland 和 IBM 通购并来达到目的的方式并不相同，Microsoft 有足够的力量全方位出击。所以如今的软件界是大公司之间相互制约的结果。大公司们在标准、理论、语言上的争来夺去，未必全然出于“软件实现”的考虑。对统一理论、统一工具、统一过程的企图，其最终目的是在整个软件工程体系中的全面胜出。
之后作者介绍了工程中的一个细节，要注重成本，不计成本的项目计划不会得到经营者的支持，毫无目的地消耗成本是项目中的慢性毒药，最致命的风险是成本的枯竭。 随后介绍了AOP和MAD/MDD。我们弄清楚了AOP 作为“思想、方法、工具”的一些基本知识，以及它的应用范围是用来考察对象(而不是设计对象)的思想方法。 MDA 架构作为一个新的软件开发方法的架构，即使在技术研究、底层协议和软件实现方面经过了持续地完善而渐至成熟，然而如果没有同样成熟的软件过程理论支持，那么它在工程中的实用价值也就有限。
在下一章中，作者谈到了平衡的问题。首先是在理论上的平衡，软件三要素，工具，方法，过程，实际上并不独立，而是相互作用的，从整体考虑，工程的整体问题仍旧是实现。而后是语言上的平衡，每个语言都应该有相应的文字描述，而且这种描述与图之间的对应关系要持续地维护下去。如果这种关系松散了、断裂了，那么下一个阅读 UML 图的人所面对的，将是无异于甲骨文出土时的困境。更大的角度上，经营者和开发者之间也需要一种平衡，老板往往不懂技术，项目经理这个中间角色就有了一种使命：协调经营者与开发者之间的沟通。目标的实现和质量的保障之间也存在平衡，时间，资源，功能三者不能同时满足，所以往往出现需求人员会把所有的责任归咎到开发人员，而开发人员又不停地埋怨需求的不清不楚或者变更的没完没了。又如果正巧需求和开发都是同一个人或者小组来做的，那么他们便会开始埋怨客户的苛刻以及工期的紧张。软件工程是灵活的，如何调节三者的需求显得尤为重要，大多数人不知究竟地使用着技巧和方法，而一旦出了问题，则归究于这些技巧和方法的不好。 而真正的问题在于，这些人并不知道这些技巧、技术和方法的原理，因而不知道变通， 也不知道回避错误。 会解决平衡的问题，才算是能够变通的工程，达到“知律而变”。