Release early and often

Proper documentation is an extremely vital part of good software. The longevity and viability of said software is greatly dependent on good documentation practices for which future contributors can read and fully comprehend to better maintain and alter the code. In a perfect world, there would be no need for documentation as said in chapter 8, every individual would be have the same coding conventions and would be able to understand any piece of code written by anybody. But sadly that is not the case, everybody has their own way of doing things; naming conventions, spacing and indentations are a couple of instances that allow for stylistic  independence/ expression (Java specifically). Although many are taught to name their variables and methods with clarity and obvious purpose, some time constraints or other factors prevent developers from doing so. There is legacy code out there with simple variable or method names designated as such to save time and to get the code working. The idea of getting the code to work first and cleaning up later is prevalent in the field, but many projects such as government contracting do not allow for this to occur. These contracting jobs are in the market for code that does what they need it to do, no government projects will pay a team to go back and clean up the code, and make it more readable. Harsh deadlines and requirements make it hard for developers to take the time to make readable code, they are just looking to meet the deadlines and complete the sprints on time. Although this is the reality of some projects, it is still imperative that said developers take that extra time to document their code, making the lives of future maintainers, or the developers themselves much easier in the long run. Proper documentation practices can go a long way in this field, and many people will be greatly appreciative for it. One must write code that is relatively easy to understand or have documentation that adequately describes what the purpose of the software. Developers should maintain good developer documentation in the code base, ensuring the future understanding of every function and module. Technical writing is the same as any other kind of writing, know your audience and be as clear and concise as possible.