In school you had to read lots of books about history and when you had finished you knew what had happened but not necessarily understood all ends. To understand more you had to discuss with your friends, ask questions to your teacher and most importantly, do the exam. The exam is not only a tool to measure your knowledge on a subject, it's a much greater educational tool to enable you to express yourself in your own way, to make your ideas clearer about something and to learn for real what was being tested. Some teachers say, and I agree, that it is in the exam that students learn most.
When you read a text (as the one you're reading now), it's quite easy to believe the author if he/she have good arguments and some facts to back them, but reading is much faster than thinking properly so you sometimes may be led to think that you agree with the author when in fact you just haven't thought enough about the subject. This is called rhetoric and it's a very powerful educational tool as well but normally used for evil purposes.
So only by reading or listening to someone is not enough to learn, you need to tell someone with your own words so you can see all inconsistencies and check better what you have misunderstood and what is in fact not true, and this is also the case when writing software. Whenever you write a method, your head is thinking on that particular method and rarely think on the global scope of what you're doing. Problems will arise when you try to use it from outside and than you have to go back and fix them (refactoring) in the original method, taking care not to break other callers.
Whenever you map the features of a program with the user (yourself some times) you can write down the use cases and build the test cases. That guarantees that you'll, at least, do what the user is expecting, but won't guarantee that you have fully understood what he/she was really expecting in order to predict problems or new features in the future. Planning future changes is important when designing software for you can predict behaviours for methods that are not explicit, create generic interfaces that are not required in the original request, all in order to increment the program in the future. Predicting changes will reduce the amount of refactoring in the long run.
Every iteration requires understanding and to reduce the amount of work in the next iterations you need to make sure nothing was left behind in the previous iteration. It's impossible however to be 100% sure but taking measures to increase the quality in each iteration will make things easier during the development and after it's release in the maintenance phase.
Also, fine grained documentation is sometimes seen as useless because most of them get discarded anyway or no one reads them, but their primary role is not to explain to other people but to yourself. Users will rarely read development documentation so they're written to other developers as well, when maintaining or incrementing the software, to understand your design decisions and techniques.
Therefore, a very important part of documentation is to clean up deprecated and archive fine-grained documentation so you can keep your head always refreshed on what the program is really doing rather than trying to remember what you did, when and why. It's very unusual to a programmer remember what he/she had done 6 months ago and why some decisions that looks stupid today had been taken. It's not unusual, however, to see them deleting or refactoring old code and finding out that it was useful for a very specific case but wasn't documented properly.
Documentation is, in fact, any written text about any decision or piece of code. It can be comments within the code, web pages, printed manuals, Unix manuals, text files etc, but each has its own uses. You can't expect the user will read comments in the code or the programmer will read web pages to find out about a particular line of code, so using the right tool is also important.
Comments in the code should never tell what are the business decisions involved, odds and ends of each arguments or how to test the program. Also, explaining variables is a bit redundant when you use meaningful names for variables. Programs that have more comment lines than code lines are also not useful as it's impossible to follow the flow of the program.
Manual pages are excellent for explaining a bit more about the program, all the options and possibilities as well as where to get more info, bugs and authors, but telling about the history of the program, it's previous versions, how-tos is a bit too over. There's where web pages are good for. You can set a whole website with discussion forums, how-tos, mailing lists, full documentations, source download, diagrams and graphics, performance statistics and much more.