一旦在Web组织中逐步培养起编写文档的文化，那么员工就会越来越依赖于这种实践方法。这种文化还有一个十分重要的优点，即如果出现人员流失和变动，那么良好的文档可以缩短新人的“交接”时间。此外，除了构成一般软件开发过程的标准代码注释、跟踪和源代码控制过程，编写文档也是一种审查方法。在一些开发专用软件的公司中，文档显得尤为重要，因为新员工一般很难理解复杂的定制应用程序，以及各个应用又是如何组成客户所访问的网站。如果文档成为这一过程的组成部分，人们就一定会对软件构建方式进行交流，工程师也会习惯于向其他团队成员介绍软件的工作方式。
为了理解这种方法的实践应用，我们可以设想一下最成功的开源软件，它们都有一些共同点:有一个能够自由协作与交流的活跃开发者社区，以及优秀的文档。当开发者协作编写出面向各种用户的优秀文档时，软件的开发和管理也会变得更容易。这个道理适用于任何组织，而且对于大型组织而言尤其重要。
将介绍各种标准文档模板，它们将帮助我们理解如何管理组织内部开发的软件。例如，一位高级软件开发者可能只会使用API规范与参考文档，然后就开发实现一个应用程序，完全不会去阅读其他的文档。另一方面，人门指南则以一种简单方式概括介绍更多信息，它将帮助一些软件开发新手快速入门并了解他们将要接触的应用程序、平台或库。用例( Use Case)文档则可以向非技术人员解释一个应用程序的用途。我们稍后将详细介绍这些模板。
有了这些信息，用来理解复杂的Web与应用程序架构的时间就将大大减少。如果没有一组能从不同角度说明指定技术的文档，那么Web开发者和运维工程师就只能自己去理解各个方面。
最重要的是，在不同的利益相关者共同编写文档的过程中，他们会发现一些深层次问题和改进软件的机会。例如，当一位工程师开始在纸上或设计模型上介绍一个Web应用程序时，其他人就很容易理解他所要表达的概念，因此可以更好地获得关于应用程序的技术性能和设计等方面的反馈信息。此外，针对不同读者编写的文档也有一定的好处。有时，业务用户可能无法读懂一个AP规范，但是画一个简单图形来说明API的复杂关系或应用程序之间的交互，就可以帮助非技术人员理解应用程序。这种文档还可以帮助初级工程师理解复杂的软件架构。
在这一方面，文档就是一种鲜活的反馈机制。将应用变成文字与可视化内容，要比通过网站建设代码或实现应用更容易让人理解。通过编写和使用文档，能够激发反馈、发现代码问题，形成对程序和过程设计的新理念。这实际上也是一种测试代码和Web应用的手段。
