书中曾提到客户不会用C，难道就会用UML？作为开发人员，我们当然希望用户能学习或者精通c语言，这样客户就知道开发人员正在做什么，或者，这样的客户还能以c语言的方式告诉开发人员他们究竟想要什么。可是，要求用户学习c语言明显是自杀式的行为。这样的用户学会用c语言向开发人员描述需求时，可能他就已经被老板开除了，因为没有用户会笨到愿意用c语言来描述他们的需求。 c语言是程序员与计算机交流的语言，而不是他与客户交流的语言。程序员面对的是计算机，但计算机不是客户。所以，我们在做用户需求分析时，不要希望用户能了解计算机语言，而是根据他们所说，转化成c语言等计算机语言与计算机进行交流，最后做出成型的软件。
沟通问题不仅仅存在与客户交流之中。还存在于与项目的各个角色之间。项目的分析报告为设计人员所看不懂，设计人员的方案为开发人员所看不懂，而开发的结果以为测试人员所看不通。等等都是沟通问题。UML的确是解决沟通问题的最佳手段之一。然而如果项目一开始就不能用它，那么强求的结果必然是痛苦的。——要让 UML 在一个没有经过相关培训的团队及其各个角色之间用起来，几乎是不可能的事。即使用得起来，也存在经验问题。千万不要指望仅仅一个项目，就能让你的组员深刻的理解 UML 的思想。使用与不适用UML，其根本问题在于沟通方式的选择。只要是行之有效，能在各个项目角色间通用，就是好的沟通方式。
软件工程本质就是实现。工程只是一种实现的途径。最初做开发的前辈们，不用什么工程或者过程，也一样编出了程序，也一样解决了问题，也一样实现了目的。而现如今，我们讲工程了，讲过程了，讲方法了，却什么都再也做不出来了。不奇怪么？工程被当成了借口，掩盖了我们做事的真正目的：“实现”。因此，我们在一个项目中常常听到说“工程要这样做”，或者“工程要那样做”，而绝少听到“项目要求这样做”或者“客户的本意是那样的”。这样的结果是：我们做完了工程( 的每一个过程) ，却没有完成项目。为工程而工程的人，都迷失在项目中了。就象开发人员迷失在一个技术的细节上一样。专注于 RUP 或者 RAD之间的区别的人，可以把每一个过程的流程图都画出来，却也被这每一个流程给捆绑得死死的，再也没有挣扎一下的力气。