我们都知道，一个新发明如果不被人们所需要，那只是一个失败品。一篇文章的观点如果不被人们所接受，那么就算文笔再好，也只是一张废纸。同样的，一个与客户需求不符的程序，哪怕它的架构再好，都只是一个废弃品。
在不同国家的人们之间，我们都一直在追寻一种有效的沟通方式，达到合作共赢的局面，于是就有了翻译的出现。翻译就相当于是这两个国家的语言不通的人之间的桥梁，翻译了解的不仅仅是这两种语言之间语法的差异，还了解他们不同的地域文化，才能做到有效的沟通。与此类似的关系就是开发人员与客户之间的关系，那么谁能搭建起这个沟通的桥梁呢？有人说是UML，但是我不这么认为，UML只是一种沟通的手段，在客户能理解的情况下，我们如果能使用它当然好。如果不能，我们总不能要求客户去学习UML之后再来与我们谈项目，就像你不能指望你所有的客户都了解C语言一样，所以只有另辟蹊径。UML的中文意思是统一建模语言，大概是创建这种语言的人希望程序员和客户都能使用这种语言去沟通，但是现实中的可行性并不高。而且更糟糕的情况可能是本身开发团队里的成员也不了解这种语言。在这样一种情况下，寻求一种有效的沟通方式是非常有必要的。与其要求他们学习一种语言，不如使用他们那个世界的通用语。客户是因为他们觉得你了解了他们的需求才会把这个项目让你们来做，并不是因为你把UML学的多么好。
如果在每一个项目开发中，客户都能在程序开发的第一现场，随时向程序员确认完成功能的有效性，修正需求或者先前的需求描述的话，那么客户的需求一定能达到最大的满足。但是在实际的开发中，这是难以达到的。所以我们的沟通方式不仅仅要有效，还要有时间限制。我这里所说的沟通，指的不是大家一起出去吃个饭，聚一聚，沟通感情。这样的沟通方式是很难以达到我们更深入了解客户需求的目的的。比如我们可以在与客户沟通之前，先在网上查询相关的软件系统的特征来抽取客户所关注的内容，与其同类的公司进行比较，通过这样的方式来设计问题，每一个问题尽可能地覆盖可能多的信息点，或者能够让客户想到更多发散性的需求。通过类似的方式，保障每一次的沟通的有效性，而不仅仅是通过吃一顿饭沟通感情这么简单的事情。
以前的电视机售卖的时候都配有电路图，看电视的人并不会用到，那么电路图是给谁看的呢？当然是维修人员。一个好的程序的评价标准之一就是便于维护。这就要求我们在开发程序的时候也要考虑到程序的可维护性，也要考虑到与维护人员的沟通方式。可以留下一些文档类的文件便于让维护人员更好地了解程序。