大道至简第四章流于形式的沟通分为五小节分别是：1. 客户不会用C ，难道就会用UML吗？2. 项目文档真的可以用甲骨文来写3. 最简沟通4. 为不存在的角色留下沟通的渠道5. 流于形式的沟通。第四章讲述的主要是沟通的重要性。
第一节客户不会用C ，难道就会用UML吗？讲述公司在接触客户，明确需求时的代沟。作为开发人员，可能更希望客户能学习或者精通C语言，然而要求客户学习 C 语言明显是自杀式的行为。因此开发人员最好不要直接面对客户。项目经理有这样的一种优势：他可以不用了解C 语言，也可以用一种非 C 的语言来与客户交流。要深入项目的需求阶段的项目经理或者调研人员，被要求深谙项目所涉的业务。但这往往我们所做不到的，因为我们是软件公司，而不是做这些( 客户的) 业务的公司。这时惯常的做法是聘请行业咨询公司( 或者个人) 来介入需求阶段，协助了解和分析需求。但是他们的解决之道是模型语言。客户不会C ，难道就会用UML吗？沟通依然流于形式。
第二节项目文档真的可以用甲骨文来写。在uml的实际应用中有两个问题：1. 大部分的使用者，以及客户的信息人员，其实并没有足够的能力，来确认这些文件的正确性与完整性。2. 除了客户不了解UML，OOAD 跟RUP 以外，另外一个更糟糕的现象就是project team 里面的人也不懂。UML的User Case由“用例图”和“用例规约”组成。规约跟我们写的需求说明书差不多，图则很简单，就是几个图形符号来描述系统边界和角色关系。显然甲骨文也能描述范围与关系。只要你运用得法，甲骨文一样可以用来画用例图和写用例规约。UML 图在一些客户眼里无异于盲人的世界，如果需要向他们做需求调研，你只能使用一种这些客户能够理解和接受的方式，例如表格、流程图以及……更深入的交谈。你要确认你的沟通方式是否有效。一旦源头确定，你就可以接下来约定在项目组中要使用的沟通方式。
第三节最简沟通 客户有时并不会把大部分精力放在项目上。“现场客户”并不经常出现。因此提出了“最简沟通”。首先 查看相关的软件系统的特征以抽取客户所关注的内容，然后综合以下两个方面的因素：1客户在公司层面的外在表现、内部机制和运营管理手段。2客户在项目中既已明确的需求和可能发生的需求，以及客户围绕其公司行为( 和方向) 所提出的需求。这样我们就了解了客户项目中所有会产生需求的信息点。最后开始设计提问，每一个提问涵盖尽可能多的信息点，尽可能的具有发散性以便形成更多的推论和假设。然后与客户交流。得到信息后，工程人员从数百条的需求条目中，整理出系统结构和模块，需求条目被映射到各个模块。最终形成系统雏形。
第四节为不存在的角色留下沟通的渠道。讲述了开发新项目时要为后人留下参考资料的重要性。很多的项目( 尤其是产品计划) 在负责人员离开后，就自然而然地死掉了。作者把这一切的原因归咎于“没有history”。历史记录(History)与注释(Comment) 不是一回事。代码中的注释是为阅读代码而留备的，而History是为整个项目而记录的。一些参考的记录内容有：1.需求阶段：与谁联系，联系方式、过程、结果以及由此引发的需求或变更；2. 设计阶段：如何进行设计、最初的构架、各个阶段的框架变化、因需求变更导致项目结构上的变化( 有助于了解构架的可扩充性) ；3. 开发阶段：每一种技术选型的过程、每一种开发技巧的细节和相关文档、摘引的每一段代码、算法、开发包、组件库的出处和评测；程序单元的测试框架；每一个设计和构架变更所导致的影响；4. 测试阶段：还记得测试用例和测试报告吗？那是最好的history之一。
第四节流于形式的沟通。其实沟通是具有目的性的，如果在没有明确目的的情况下与客户沟通，那将是浪费客户和自己的时间。这种目的，可以是了解项目的讯息、挖掘潜在的项目……最末了，才是交流感情。沟通问题不仅仅存在与客户交流之中。还存在于与项目的各个角色之间。项目的分析报告为设计人员所看不懂，设计人员的方案为开发人员所看不懂，而开发的结果以为测试人员所看不通。等等都是沟通问题流于形式的沟通，可能是使得你的项目被不断推翻和不断延迟的最直接原因。