The often provocative Chuck Moore (inventor of the Forth language) gave the following advice[1]:


  Use comments sparingly! (I bet that's welcome.) Remember that program
  you looked through - the one with all the comments? How helpful were
  all those comments? How soon did you quit reading them? Programs are
  self-documenting, even assembler programs, with a modicum of help from
  mnemonics. It does no good to say:
  
  LA B . Load A with B
  
  In fact it does positive bad: if I see comments
  like that I'll quit reading them - and miss the helpful ones. What
  comments should say is what the program is doing. I have to figure out
  how it's doing it from the instructions anyway. A comment like this is
  welcome:
  
  COMMENT SEARCH FOR DAMAGED SHIPMENTS


Should comments say why the program is doing what it is doing?



In addition to the answers below, these two Programmers posts provide additional insight:


Beginner's guide to writing comments?
An answer to Why would a company develop an atmosphere which discourage code comments?


References

1. Programming a problem-oriented-language, end of section 2.4. Charles H. Moore. Written ~June 1970.


  Should comments say WHY the program is doing what it is doing?


Unequivocally yes. There don't necessarily need to be many comments, mind you, but if you have them, WHY is the only question worth answering outside of a few bizarre fringe scenarios. The reasoning is simple. If I read your code, good or bad, I can see what the program is doing. I have no idea why. HOW seldom has anything I don't know. WHY is frequently based on history, weird portions of the problem domain, or hacks around third party dependencies.
