Documenting legacy code-bases
I would highly recommend following the scout rule with legacy code-bases.
Trying to document a legacy project independently of working on it will just never happen. Even if you get in contractors to do it, as soon as they finish the project, that documentation will start falling behind all over again, because developers haven't got into the habit of updating it.
In-code documentation
The most important thing is to use the documentation facilities in your chosen development environment, so that means pydoc for python, javadoc in java or xml comments in C#. These make it easy to write the documentation at the same time as writing the code.
If you rely on coming back and documenting things later, you may not get around to it, but if you do it as you are writing the code, what needs to be documented will be fresh in your mind. C# even has the option to issue a compilation warning if the XML documentation is incomplete or inconsistent with the actual code.
Also, if reviewing documentation becomes part of your code review process, everyone can be encouraged to contribute, fostering a sense of ownership of the documentation as well as of the code.
Tests as documentation
Another important aspect is having good integration and unit tests.
Often documentation concentrates on what classes and methods do in isolation, skipping over how they are used together to solve your problem. Tests often put these into context by showing how they interact with each other.
Similarly, unit-tests often point out external dependencies explicitly through which things need to be Mocked out.
I also find that using Test-driven development I write software which is easier to use, because I'm using it right from the word go. With a good testing framework, making code easier to test and making it easy to use are often the same thing.
Higher level documentation
Finally there is what to do about system level and architectural documentation.
Many would advocate writing such documentation in a wiki or using Word or other word processor, but for me the best place for such documentation is also alongside the code, in a plain text format that is version control system friendly.
Just like with in-code documentation, if you store your higher level documentation in your code repository then you are more likely to keep it up to date. You also get the benefit that when you pull out version X.Y of the code, you also get version X.Y of the documentation. In addition, if you use a VCS friendly format, then it means that it is easy to branch, diff and merge, just like your code.
Not only that, but if you use something like readthedocs then you can publish version specific documentation for each software release.
I quite like rst, as it is easy to produce both html pages and pdf documents from it, and is much friendlier than LaTeX, yet can still include LaTeX math expressions when you need them.
I'm not sure if there's a single "best way", but from your description, it sounds like every developer is doing his/her own way of storing documentation. Get a buy-in from everyone on a single method of storing documentation, and it'll be a lot easier to keep it organized.
Besides the "find the best way for you" answer, I'd say to at least look for a solution that makes it easy to search for documents. At one company, I set up a wiki that contained links to files thrown all about serverland, which suddenly made it much easier to search for and locate documents no matter where they were. Once other users started using the wiki to find documents, they also started updating it to either link new documents, or by just creating a wiki entry as the document.
I'd love to hear from anyone else if they know about free version control systems that work well with documents. The only thing that comes off the top of my head is Sharepoint, which isn't exactly free. I've seen unofficial versioning systems where people have an "Archive" folder, and simply put past revisions of a file in that folder, with the newest revision being in the same folder level as "Archive".
Best Answer
It all depends on the purpose of documentation.
Two GENERAL cases:
Documenting the inner working of a piece of code, down in the gory bits and algorithms - the things that are not important to an outside world because they are hidden under an abstraction or behind an API - is probably best done in the code. Because outside the code nobody else knows or cares.
Things that go further - API's, general design principles, interface definitions, messages that get exchanged, and so on - are a different matter. These should be defined in painful detail in external documents. And only changed later - with the blessing of god.
By APIs I don't mean the stuff that appears in a C header file, or some class definition (though the lines are getting blurry). That can usually be handled fine in the source.
There will be degrees in between that require thought.
Perhaps a few examples would help:
The algorithm you use to calculate days between dates should be documented in the code.
The multi-processor message passing system you defined with failover redundancy and process porting at run-time should be documented in documents.
The plugin architecture for your new driverless vehicle control system (you know, the one that allows you to add a new flight module at run time without rebooting), where the plugins are developed by an outside company - well, documentation in source alone would be very problematic, use a document with words in that describes interactions, dependancies, time ordering, gotchas, exceptions, limitations, and so on. With diagrams. All in one place.
You get the idea - there are degrees to these things, and reasons for going either way. Make an intelligent and well-considered decision.