Code only says what it does
<i>This is a major problem with code: You don&#x27;t know which quirks are load-bearing. You may remember, or be able to guess, or be able to puzzle it out from first principles, or not care, but all of those things are slow and error-prone.</i><p>This is a problem from both the negative (not breaking things) and positive (knowing how to add things) perspectives.  The positive perspective was written about by Peter Naur in one of my favorite software engineering papers, &quot;Programming as Theory Building,&quot; in which he describes how the original authors of a codebase have a mental model for how it can be extended in simple ways to meet predictable future changes, which he calls their &quot;theory&quot; of the program, and how subsequent programmers inheriting the codebase can fail to understand the theory and end up making extensive, invasive modifications to the codebase to accomplish tasks that the original authors would have accomplished much more simply.<p>I highly recommend finding Naur&#x27;s paper (easily done via Google) and reading it to understand why divining the &quot;theory&quot; of a codebase is a fundamentally difficult intellectual problem which cannot be addressed merely by good design, and not with 100% reliability by good documentation, either.