What kind of code overview documentation do you write?
As suggested, I have closed the question posed [here][1] and have broken it up into separate questions regarding code documentation to be posed throughout the day.

----------
This is the final question in the series.  

  - The first part: [How do you document
    your methods?][2]
  - The second part: [Are tests valid
    documentation?][3]

This question has to do with what documentation overview do you provide of your system.  

You've doc-commented your API, you've written the unit tests, now what kind of documentation do you provide to pull it all together?  Is there only documentation from the point of view of the user or do you make an extra effort to provide maintanance programmers with an overview of the system's logic and control flow?  Do you discuss why your program is structured the way it is and how far down that rabbit hole do you go?

Should this overview documentation be provided in a single document or broken down by the system's major components?  Keeping in mind that the target audience are other programmers what is appropriate for length and tone? Do you mandate what concepts the programmer should be familiar with or is that being to bossy?

Do you write this documentation in a big bang at the end or as you go?  If you do it as you go then how do you handle keeping it in sync with design changes?

What do you do for this important step and what do you like to see has been done when picking up someone else's project?


  [1]: http://stackoverflow.com/questions/63297/how-do-you-do-documentation
  [2]: http://stackoverflow.com/questions/63801/how-do-you-document-your-methods
  [3]: http://stackoverflow.com/questions/64898/are-tests-valid-documentation
What kind of code overview documentation do you write?
===

As suggested, I have closed the question posed [here][1] and have broken it up into separate questions regarding code documentation to be posed throughout the day.

----------
This is the final question in the series.  

  - The first part: [How do you document
    your methods?][2]
  - The second part: [Are tests valid
    documentation?][3]

This question has to do with what documentation overview do you provide of your system.  

You've doc-commented your API, you've written the unit tests, now what kind of documentation do you provide to pull it all together?  Is there only documentation from the point of view of the user or do you make an extra effort to provide maintanance programmers with an overview of the system's logic and control flow?  Do you discuss why your program is structured the way it is and how far down that rabbit hole do you go?

Should this overview documentation be provided in a single document or broken down by the system's major components?  Keeping in mind that the target audience are other programmers what is appropriate for length and tone? Do you mandate what concepts the programmer should be familiar with or is that being to bossy?

Do you write this documentation in a big bang at the end or as you go?  If you do it as you go then how do you handle keeping it in sync with design changes?

What do you do for this important step and what do you like to see has been done when picking up someone else's project?


  [1]: http://stackoverflow.com/questions/63297/how-do-you-do-documentation
  [2]: http://stackoverflow.com/questions/63801/how-do-you-document-your-methods
  [3]: http://stackoverflow.com/questions/64898/are-tests-valid-documentation