I think that responsibility should be distributed to the entire work force. I can't imagine one person having enough domain knowledge to keep all documentation updated. I like when it's built into the development process

The big question for me is: What kind of documentation are we talking about? Are these API docs? Are these guidance docs for things like UI or architectural design? Are these docs intended for end-users for using the application (like help docs)? There are a lot of very different kinds of docs with very different audiences. It's unlikely that a single person would be qualified to handle all of these. So, what kind are you talking about?

I would say yes, but in the capacity of Quality Manager, who manages the overall project quality. This ranges from correct timesheets to approval of designs, to completeness of documentation. He/she does not produce, but manages the production and quality of said products by project members.

Consider these scenarios:

You have documentation for a particular function or class. (source doc)

You have documentation for how the program is supposed to operate and how to tell it what to do. (purpose of code + manual for how things work + configuration documentation)

If you are providing a service, then you must keep track of how everything works together. (system documentation)

For the first, your programmer's tools should be doing this automatically. Maybe details are left out, but it's something THEY should be adding and filling in when it gets overlooked.

For the second, yes, you absolutely someone who is a technical writer. I can't tell you how many projects I've found on github where there is literally:

1. No explanation of what the project is.
2. No explanation of the theory underpinning its function.
3. No explanation of how to install it.
4. No explanation of how to configure it or what the configuration options do.

As a programmer, but someone who can speak fucking English (yes it is a country and I have been there), this infuriates me. I usually find that these projects are garbage, despite how convenient they may be once you figure out 1-4.

For the third type, you would normally have your network person, engineering person (devops), and programmers get together to figure out all the little pieces of information that are needed to rebuild your system in the event of a failure. This information is tremendously useful for when a new person comes onto the team or when a piece of software fails or even when hardware bites the dust. Every once in a while, you should practice rebuilding everything from your notes to make sure it's all up to date - preferably with VMs in some kind of hypervisor environment.

Hope this helps.

It depends on his technical knowledge. It is an idiot then he is going to waste time from developers. But it would be a big welcome.

However there is something else, if a developer has to write some documentation, then he also has to think about his solution and discover his cool one-liner might not be that easy to document and even have a big design flaw.

I might be off topic, but I think that keeping the docs as close to the code as possible is one way to ensure that the documentation is up to date. Using things like doctest and Sphinx autodoc work for me, but I work on small projects.

You're thinking of a Technical Writer. Someone who has the necessary understanding of the technology and can translate it into (somewhat) usable english for everyone else.

This is largely what I do. Although documentation is a small subset of my overall duties.

Documentation is the job of whoever is in charge of the spec, who is probably a manager of some type already. A necessary requirement of having a spec is being able to communicate that spec to everyone else.

If its a large program or package (the linux kernel for instance) then developers usually (hopefully) document their own modules and a maintainer team collaborates on keeping the documents up to date.

Smaller programs can get away with one maintainer pulling together documentation.

Yes. This role should be taken by an experienced assistant project manager, and full documentation should be a standard project deliverable.

I have a process that generally works well for a small team (~15 people). I have the programmers do this for API docs when they develop new or modify existing functionality. If they don't add/modify a doc block that can be generated properly, their pull request doesn't make it through code review. User documentation is a separate process that generally involves the UI/UX team, the QA/UA team, and select members of the dev team to compile everything and make a nice, pretty, digestible PDF.

Documentation managers don't write books. Job Description. You need a Technical Writer.

There is a difference between a documentation manager and a technical writer.

Technical writers ensure that your users understand how your program is to function. I know you think you can write it yourself, but trust me on two things: 1. Every moment you spend writing docs for your users is time you aren't coding. Write a spec on what the system does and give it to QA and a tech writer. The Tech Writer will verify what you wrote against the reality of the system as they write the user docs and QA verifies both the docs and the program. 2. You can neither write as well as you think you can, nor write without ambiguities.