I think I can understand both sides in this discussion. I do subscribe to the XP philosophy and how they stress avoiding duplication of information, i.e. don't say something in the documentation that can be read from the code.
On the other hand I still feel, and I think most people agree, that there still is a strong case for technical documentation. At many times it may not be possible to learn easily from the code base what constitutes best programming practice. Different applications may take different approaches, which one should the novice developer choose? Also, as Andrew so well points out, the code doesn't necessarily communicate the design tradeoffs, known limitations or the concepts and use-cases that drove development.
We should try to keep code level information in our docs that can be expected to change to a minimum and rather link to a dynamic api documentation. We must also try to keep whatever duplication still ends up in the docs in sync with the code.
As a reader of technical documentation you are typically aware of the fact that every implementation detail may not be 100% accurate. However, that doesn't render the documentation useless. I believe the design documents that we have inherited from aD illustrate this point.
