第四章一开始，就提出了一个尖锐的问题：“客户不会用C，难道就会用UML吗？”。作为程序开发人员，我们当然希望客户能够懂得C语言，这样我们与客户的沟通就会更加方便，然而C语言只是我们程序员与电脑交流的语言，我们不可能要求客户能够了解他。既然不能要求客户会C语言，又怎么能够要求客户会看似简单细致的UML呢？从此我们可以看出，做程序的过程中，我们要与客户沟通，不是依赖种种看似高深的语言，重点是要让客户真正接受我们的项目。
第二节作者提出了一个很有趣的概念:：“项目文档真的可以用甲骨文来写”。UML的使用者未必就能用好UML。要让别人读懂你的项目，就要用别人最熟悉的语言，比如要让考古学家读懂项目，用甲骨文必然比用C语言有优势。我们所要追求的是我们的沟通方法是否有效，而不是我们所用的沟通方法是不是UML。换句话说，我们追求的只是结果，而不是得到这个结果的方式。
在做一个项目的过程中我们需要沟通，然而作者在这里提出了一个名叫最简沟通的概念，最简沟通指的是我们要通过查阅客户的资料来推测他的要求，这样我们就可以开始设计提问，这样我们的提问就可以涵盖更多的方面。在和客户沟通的过程中，我们要保证沟通的有效性，每一次沟通都是向客户了解更深层次的需求的机会，在这个机会中我们有一个模型，我们就可以让他们来操作并提出意见。而不是在吃饭的时候沟通，因为那样并不能达到目的。
在文章里，作者提出：“要为不存在的角色留下沟通的渠道。”正如我们的历史有5000年，然而仅仅有3000年有史可查。资料的缺失让我们的编年过程变得异常复杂。其实编程也是一样，最困难的是维护一些旧项目。所以说在编写一个项目的过程中，我们要为后人留下注释，为不存在的人留下沟通的方法，防止别人再接手项目的时候两眼一黑，这样的话我们就能让那些人找到问题的源头。
很多时候，我们可以选择各种的沟通形式。但是沟通不能留于形式，沟通的过程在大多数的情况下只被看成交流感情，这便成了形式，而且是客户最讨厌的一种形式。这对于共同的初始意义显然是背道而驰的。UML的确是一个方便交流的工具，但是如果这样的工具成为定势，便没有了他作为工具的初衷了，千万不要指望仅仅一个项目，就能让你的组员深刻理解UML的意思。而且留于形式的沟通，可能使你的项目被不断推翻和不断延迟的最直接原因。
