If your method names don't make their purpose immediately obvious then they aren't well-named.
Relying on documentation over well-named classes & methods will invariably come back to bite you. All it takes is a few instances of people forgetting to update the documentation and you end up with a horrible mess.
example:
BAD
private void Update(string sValue, DateTime dValue)
{...}
BETTER
private void UpdateEmployeeInformation(string jobTitle, DateTime hireDate)
{...}
What about the second version needs documenting? The name identifies what its purpose is and the param names make it obvious what is expected to be passed.
If your methods are so long and complex that they require a novel to explain you need to break them up into logical bits of functionality that can be well-named and highly focused. That, IMHO, is much easier to understand than some poorly written inline documentation that may or may not be up to date - I'm STILL going to read through all of the code to make sure it matches what the documentation says it should do and in most cases I'm going to assume that the documentation hasn't been maintained and ignore it.
You should also have unit tests that flex the code and make the functionality even MORE obvious. With well-named classes, methods, and unit tests what purpose does additional documentation serve?
