没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。

　　然而，过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间，并且要使这些文档和代码保持同步，要花费更多的时间。如果文档和代码之间失去同步，那么文档会变成庞大的、复杂的谎言，会造成重大的误导。
　　对于团队来说，编写并维护一份系统原理和结构方面的文档将总是一个好主意，但是那份文档应该是短小的（short）并且主题突出的（salient）。“短小的”意思是说，多有一二十页。“主题突出的”意思是说，应该仅论述系统的高层结构和概括的设计原理。
　　如果全部拥有的仅仅是一份简短的系统原理和结构方面的文档，那么如何来培训新的团队成员，使他们能够从事与系统相关的工作呢？我们会非常密切地和他们在一起工作。我们紧挨着他们坐下来帮助他们，把我们的知识传授给他们。我们通过近距离的培训和交互使他们成为团队的一部分。
　　在 给新的团队成员传授知识方面，好的两份文档是代码和团队。代码真实地表达了它所做的事情。虽然从代码中提取系统的原理和结构信息可能是困难的，但是代码 是惟一没有二义性的信息源。在团队成员的头脑中，保存着时常变化的系统的脉络图（road map）。人和人之间的交互是把这份脉络图传授给他人的快、有效的方式。
　　许多团队因为注重文档而非软件，导致进度拖延。这常常是一个致命的缺陷。有一个叫做“Martin文档第一定律（Martin’s first law of document）”的简单规则可以预防该缺陷的发生：
　　直到迫切需要并且意义重大时，才来编制文档。