very often we have our project’s piece of code under a versioning system. This has proven to be of real help. It helps the developer to observe the changes, remember the reason behind them and code just for the differences.
The documentation should obey the same rules.
“My taller friend” pointed out that the documentation is split, by functionality, in at least two categories. One would be to describe the characteristics of an entity or process. The second to describe a list of checks to be made in order to validate an entity.
By combining those two we look at the ideal documentation as follows. A dynamical part, with unchecked checks that is included automatically after each clone of the previous version. A static part that is being altered from one version to another.
Real life simplified example:
We have a a folder that can contain an infinite depth of folders and an infinite number of files.
We work hard enough to create a good enough script that validates that each folder has the require image and name based on the documentation provided by the stakeholder.
We copy our folder onto a new location and add a few folders and files.
Now we have two ways of writing some documentation in order to help the automation:
We work hard enough, again, to parametrize the initial script based on the re-written documentation.
We copy the first script and just alter the changes.
The versioned documentation allows the team to adapt faster without over-thinking the technical solution.
I would like to read your opinions,