沒有文檔的軟件是一種災難。代碼不是傳達系統(tǒng)原理和結(jié)構(gòu)的理想媒介。團隊更需要編制易于閱讀的文檔，來對系統(tǒng)及其設計決策的依據(jù)進行描述。

　　然而，過多的文檔比過少的文檔更糟。編制眾多的文檔需要花費大量的時間，并且要使這些文檔和代碼保持同步，要花費更多的時間。如果文檔和代碼之間失去同步，那么文檔會變成龐大的、復雜的謊言，會造成重大的誤導。
　　對于團隊來說，編寫并維護一份系統(tǒng)原理和結(jié)構(gòu)方面的文檔將總是一個好主意，但是那份文檔應該是短小的（short）并且主題突出的（salient）。“短小的”意思是說，多有一二十頁。“主題突出的”意思是說，應該僅論述系統(tǒng)的高層結(jié)構(gòu)和概括的設計原理。
　　如果全部擁有的僅僅是一份簡短的系統(tǒng)原理和結(jié)構(gòu)方面的文檔，那么如何來培訓新的團隊成員，使他們能夠從事與系統(tǒng)相關(guān)的工作呢？我們會非常密切地和他們在一起工作。我們緊挨著他們坐下來幫助他們，把我們的知識傳授給他們。我們通過近距離的培訓和交互使他們成為團隊的一部分。
　　在 給新的團隊成員傳授知識方面，好的兩份文檔是代碼和團隊。代碼真實地表達了它所做的事情。雖然從代碼中提取系統(tǒng)的原理和結(jié)構(gòu)信息可能是困難的，但是代碼 是惟一沒有二義性的信息源。在團隊成員的頭腦中，保存著時常變化的系統(tǒng)的脈絡圖（road map）。人和人之間的交互是把這份脈絡圖傳授給他人的快、有效的方式。
　　許多團隊因為注重文檔而非軟件，導致進度拖延。這常常是一個致命的缺陷。有一個叫做“Martin文檔第一定律（Martin’s first law of document）”的簡單規(guī)則可以預防該缺陷的發(fā)生：
　　直到迫切需要并且意義重大時，才來編制文檔。