To document, or not to document? That's not really the question. Of course you should document! You know the saying, "What would happen if Joe Schmoe got hit by a bus tomorrow and someone had to pick up on his project where he left off?" Without proper documentation on Joe's project, the new developer would be left spending unwanted time getting up to speed which is neither time efficient nor cost effective. So obviously as developers it is our responsibility to document our work (i.e. setup, configuration, requirements, changes, etc...) so that project transition can go over as smoothly as possible. And let's not forget that you are going to forget, so documenting as you go can help yourself down the road when the client says "You know that thing you did 5 months ago...". No, the real question is how much to document! Some developers go over board and document every single line of code (is this really necessary?): // Increment counter by 1 myCounter++; Some developers don't even bother to write a single comment. This is a dangerous practice and I wish FxCop or unit testing would break the build if this were the case. Documentation should be concise, thorough, and informative while not taking up all of your time. Just as it is wise to use the 10% rule when starting a task to determine if you can accomplish your goals in the given amount of time, you might consider using something similar in allowing time to document your work.