I neither expect people to make reams of documentation, not hope that it will be user friendly like the head first books, but I expect it to eliminate the need for hours of analysis and wasteful KT sessions. If it is not simple, concise, illustrative and user friendly, the developer or technical documentation engineer own the responsibility for it and be made to fix it. IMHO, I feel that we should have a documentation review after a project is delivered. What are the strategies to be used for creating decent documentation for the systems and code of any project, regardless of its complexity ? Are there any good examples of when minimal or no documentation is needed ? So, I am wondering if there is a way to encourage and enforce good documentation practices in a company or project. Difficult deadlines leave little time to document.(If no one can understand your code easily, then you might not be easily replaceable.) Developers don't like to do anything but code.

I learned that documentation is not given the attention it deserves because of the following reasons: It also creates the need for KT/Knowledge transfer sessions for newcomers to a project. Hence its difficult or impossible for anyone, including the developer to document the code.Īs a result, I have had to go through a lot of code and talk to many people to learn things. Hiring bad developers or not mentoring the good ones.There is little or no documentation for how the code fits into the system or business processes.Method and variable names are not self describing.In all my software development stints, I have had to deal with poorly documented code. But, a lot of code in public projects such as git and internal projects of companies is poorly documented and not very newcomer friendly. There are some good examples of well-documented code out there, such as java api.

Program that writes code for you