The problem: Documentation is in code in the form of docs, its in wiki websites, its written down on notes, in diagrams and issue management systems.
When documentation is so spread out, how does one manage to keep it up to date and relevant?
The problem: Documentation is in code in the form of docs, its in wiki websites, its written down on notes, in diagrams and issue management systems.
When documentation is so spread out, how does one manage to keep it up to date and relevant?
What you need to do is develop a single source of information.
Depending on the tools and processes that you use, you probably don't need it in all of those places. I'm not sure what your requirements for documentation are, but that will likely drive what tool you use as the single point of reference. Minimally, you should start collating everything electronically and make it generally available to the team - get it out of physical paper and into electronic sources that are searchable, indexed, and backed up.
From there, decide on the best methods of capturing information for your needs.
Make updating the various documents part of your "definition of done".
Assuming you are using agile methods, your work will be broken down into tasks. Any change to the primary documentation (the code) will likely trigger the need for changes to supplementary docs (tests, wiki entries, comments, diagrams, word docs etc). So as part of the task, the assigned person should update affected docs and those docs should be checked as part of the reviews of the changes made by that task. Only once everything (not just the code) is updated, checked-in, reviewed and tested, should the task be considered complete.
Alas, few organizations actually succeed at curating and then keeping documentation both accessible and up-to-date.
I am a contract engineer who has worked for more than 120 distinct companies, some of which you know of.
Large (50,000+ employee) companies might have effectively no standards or systems for documentation. Or they have an onerous, one-size-fits-all system. Neither works very well in practice. The former because it just doesn't get done. The latter because the difficulty of providing useful writing is high and updating it is even more painful.
Small companies (less than 50 employees), on average, do a much better job of requesting and maintaining internal and external documentation for computer software. I note that the best documentation is the internal flavor written by the engineer and inserted into the source code at the time the code is written. Automatic extraction tools nicely encourage this practice being followed.
One- or two-person projects also usually do quite a good job of keeping documentation together with the source code and keeping it relevant.
Open source software perhaps have the best functional examples. Look at the Linux kernel: The architectural and how-to information is part of the git repository and appears in the Documentation/
subfolder at the root of the project.
@ThomasOwens mentioned the most important part, Single Source
So you should start,
You can also have a distributed source system which is managed from a single place!
If you managed to keep all of your docs in the same place, then you can distribute read-only copies to anywhere you want.