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