How To Approach The Internal Documentation Of Your Software Projects?
How To Approach The Internal Documentation Of Your Software Projects?
Many Software Architects, Developers, and Leads face this question for their projects — whether they should document their projects? If yes, how much? No, we are not talking about the required documentation that almost every software project needs, like the customer-facing documentation. By “internal documentation”, I am talking about technical documentation like Architecture and Design documents. In this post, we will discuss how to approach such internal documentation.
Why Document Your Project?
This is the most important question. Simply put, what is your intent behind documentation? Are you planning to use it as a tool that can help you build more quality software or are you simply putting together some artifacts for the sake of it? And, this is not just a question for the Architects and Designers, but also the entire team. After all, when you are investing time and effort in the documentation, most of the team should benefit from it. Projects that take the approach of using documentation as a tool to build more quality software not only benefit from it, but these have more useful documentation.
