大道至简的阅读接近了尾声，作者在第七章为我们介绍了“现实中的软件工程”，在第八章为我们辨析了思考与思想的区别。
第七章先是为我们介绍了大型软件公司的发展，最后谈到软件业界如今的局面，不是一些人(例如程序员或者评论家们)争争吵吵的结果，而是大公司们相互制衡的结果。Borland 与 IBM，IBM 与 SUN，以及 SUN 与 Apple都在做着相同的事， 又都有各自的算盘。他们一面打压对手的优势，一面又借助对手和同盟的力量来削弱自己的劣势或者补充实力。 跳出到局外来看，并不是说 Microsoft 是他们的共同对手，而只是因为 Microsoft 占在了峰头浪尖，便成了众矢之的。所有人面对的并不是Microsoft 的这个名字，而只是这个地位，无论谁成就了这个地位，都将承受相同的风险与压力。 当然也包括机会。 大公司们在标准、理论、语言上的争来夺去，未必全然出于“软件实现”的考虑。对统一理论、统一工具、统一过程的企图，其最终目的是在整个软件工程体系中的全面胜出。 算盘上的绝大多数人，只是用于计算胜负的一枚算子。
因而，除了软件本质力量的推动之外，商业因素也推动着软件工程体系的发展。大公司们的争夺战的最终结果，已经开始把软件工程，从原始的“自生演进”状态，逐渐推进到“它激发展”的状态上了。这种它激发展可能会影响到软件工程发展的速度， 然而在各个工程层面上的关注点并不会发生变化。在“程序”与“方法”层面关注于“(具体的)实现”的；而在“过程”和“工程”层面，更首要考虑的是团队问题。从角色的角度上来说：开发经理思考项目的实施方案和管理具体的开发行为； 而项目经理则保障团队的稳定性和一致性。
第八章为我们介绍了软件工程的三个要素：工具、方法与过程。由于方法在过程环节以及过程总体层面上具有贯通性，因此保证“方法(或其行为)”的实施的“工具”也会出现在过程的各个环节和层面上。因此这样得到的软件工程模型将可能象太极图一样由阴阳交汇而生万物。工程的整体问题仍旧是“实现”。软件工程三个要素的价值中主要告诉我们应该回归到软件工程的本体上来思考问题， 而不是仅关注于每一个局部的要素。始终要知道工程的整体问题仍旧是“实现”。UML 与甲骨文都是符号文字，都具有象形含义。在使用UML时，我们应该有相应的文字来描述它。这样，我们才能很好的运用UML。角色的关注层面不同，角色间的交流就会有些不同，有些不畅。实现目标和保证质量的矛盾起源是在项目的平衡三角(时间、资源和功能)中讨论的是目标问题，但并不讨论质量问题。
软件工程是灵活的，在软件开发中很多常见的问题，一些人不知究竟地使用着技巧和方法，而一旦出了问题，则归究于这些技巧和方法的不好。只能说这些人不会变通，不会灵活的运用，所以如作者所说：死读一本《软件工程》的人不会做真正的软件工程。