Little discursive notes about why one thing works and something more obvious doesn't can be really helpful. Commentary about the code you didn't write can be helpful.
But in my experience on large projects that kind of documentation becomes:
# do_my_foo() is a function accepts a float and
# returns a float, performing necessary calculations.
double do_my_foo(double inarg) {
.
.
.
That is, they lie, they rot, and, since it's a "requirement" the programmer wasn't inclined to perform, they aren't informative, either.
