我们编程是从现实需要到计算机，从用户需求到我们软件工程的实现。转而由软件工程再来看现实中的软件工程。《战国策．秦策》 中讲到：“王不如远交而近攻，得寸，则王之寸；得尺，亦王 之尺也。”就拿Rational被IBM收购这件事来说。IBM 得到 Rational 的最大好处是在软件工程方面，快速地拥有了一套成熟的理论体系和实作工具。还有在语言方面，，IBM 注意到 JAVA 作为平台中立的语言 特性，以及它在大型应用工程方面的成功表现，作为扼制 Microsoft 的平台优势的唯一途径，这是它成功的地方所在。同样正如我们所知的那样，IBM选择亲近开源界。开源界给了IBM一种对抗的背景和实力，而 IBM 只需要做到把握这种力量， 就可以在潮流中稳如磐石。 要知道，把握力量总之比创造力量来得经济。这里我们不得不把软件工程上升到另一个更高的层面，那就是：软件工程=实现+团队+经营。事实上 ，经营真的很重要。良好的企业经营才可以让一个企业获得更多的项目从而获得更多的运作资金。这或许是软件工程所告诉我们的企业经营之道。
学了这么久的软件工程，软件工程告诉我们的到底是思考还是思想呢。思考问题的方法可以是由点及面的，也可以是统揽全局的。换成业界最常用的词汇，就是“自上而下”还是“自下而上”的区别。拿UML来说，这可以说是软件工程的一种思想。有人拿UML和甲骨文相比，UML与甲骨文都是符号文字，都具有象形含义。然而这并不表明 UML 符号本身能表达多么丰富的含义。如果要象甲骨文一样用几代人、上千册的论著去解释它，那么 UML 图的价值也就只剩下象征性的意义了。好在UML图有自己独特的意义，清晰易懂。其实我们要明白一件事：经营者离开发者很远，反之亦然。由于我们所扮演的角色不同，因而我们的关注点也各不相同。从而我们就会有矛盾产生，那就是实现目标与保障质量之间的矛盾。我们到底该满足哪一点。在需求阶段我们就会面临“目标”的问题。然而大多数时候，与此相反的是我们会在项目交付和试用时 才会碰到客户在质量上的投诉。 需求人员会把所有的责任归咎到开发人员，而开发人员又不停地埋怨需求的不清不楚或者变更的没完没了。又如果正巧需求和开发都是同一个人或者小组来做的，那么 他们便会开始埋怨客户的苛刻以及工期的紧张。或许我们在一开始就错了，只是定错了自己的目标。如何选自己想要的结果是我们必须要经历的一个权衡阶段。
这个如作者说的：软件工程是灵活的，很多人认为我们是技术党，其实我们是一个服务行业，服务于使用我们所写的软件的使用者。从用户的角度去思考软件，我们该如此做。