Good point. And I'm not saying documentation is not needed. But that documentation should document the "theory" that already exists, or should exist in the code. When code is documented we do that in terms of the names of modules and classes and methods that exist in the implementation. But if those don't make much sense then neither does the documentation.

Maybe a good metaphor is to view the code as a simulation of something, and the documentation as the description of what that something is and how it behaves.

For instance say the software implements matrix multiplication. It is easy to document if its "units" correspond to the well-known concepts from the theory of linear algebra. But if the code implemented matrix multiplication but used random names for its modules classes and methods it would be difficult to explain what the code does.

Any explanation must assume that whoever reads it has a basic understanding of the basic concepts the software calculates and manipulates. But as said it is challenging to come up with such a theory and that must be done when the code is written, so the code itself reflects that "theory".