You say it's obvious, but really emphasize documentation: A high-level description of what the software is supposed to do. A medium-level description of rough

You say it's obvious, but really emphasize documentation: A high-level description of what the software is supposed to do. A medium-level description of roughly how the software is designed. Explain how the user-level interface maps to the code modules, for example, what functions are called when the user engages feature X? Feature Y? Feature Z? In my opinion, that kind of documentation is immensely more useful than in-the-code comments, but don't neglect that either. Use meaningful variable names in all but the most trivial situations. Write real comment headers on your functions, not just the bare minimum required by Doxygen-type systems. It's hardly useful at all to document the parameters and types of your function when you can see that looking at the function signature itself. [Edit: ...so explain what the parameters are for.] Will documentation have to be maintained? Yes. If you make major design changes, you'll need to change the design document. If you make significant code changes, you'll need to change the code comments. But after being pulled in to fix/update/port a variety of hideously undocumented projects, I cannot tell you how much good documentation along these lines is appreciated. Can a developer get by without documentation, and just trace through the code by hand? Of course. But please don't make us do that. :-)