Stats on the average percentage of time required to create "usable" documentation

Question

UPDATE: I've gotten a lot of feedback, but no info on what percent of time people spend on docs. To keep it simple, say the docs are for developers and peer reviewed; meaning the peer understands how to do it, and the comments are more for the what is being done, not how to do it from scratch; which in my case is the request, just don't think the request is common.

Been working a project for 2 months, and it's done. When the project started, documentation was not a requirement; focus was "get it done." So, all the sudden there's an interest in creating documentation for the project... that's 100% turn-key, meaning that someone with no understanding of anything, would be able to do everything required to duplicate the work done.

In case it matters, the project was a data profiling, extraction, transformation, and loading themed. Meaning I was given sets of data, a final state of the data -- and figured out all the issues/solutions to make that happen.

Just wondering if anyone has seen stats on the average percentage of time take to write docs.

(Have questions/feedback, just comment -- thanks.)

Answer 1

So, all the sudden there's an interest in creating documentation for the project... that's 100% turn-key, meaning that someone with no understanding of anything, would be able to do everything required to duplicate the work done.

Do they actually want developer or user documentation? To me it sounds like the former, but it is quite unclear.

I would say this is a completely unrealistic expectation. Of course depending on what "no understanding of anything" actually means: a person with no programming background? or one not experienced in the specific language / platform / domain? Or ... ?

Anyway, writing such detailed documentation is a huge task, much better suited for a professional document writer than a (however experienced) developer. And its result would quickly get obsolete - the more detailed the docs, the faster it gets out of sync with the code.

Answer 2

It's impossible to answer because the meaning of usable depends of your specific case. Giving us more precisions will make the question too localized.

Therefore I can't only answer that such stats doesn't exist and if they exist, they are not reliable.

To address that issue, I usually build documentation on demand after I did the basic stuffs. Sort of lazy loading for documentation.

Answer 3

there's an interest in creating documentation for the project... that's 100% turn-key, meaning that someone with no understanding of anything, would be able to do everything required to duplicate the work done

Unfortunately that level of precision means that your project documentation needs to include minutes on all of the decisions and trade-offs that were made, by whom, and why that person's decision was authoritative: this is very hard to reconstruct ex post facto. Fortunately that level of precision is almost certainly unnecessary, because your project has already been completed: no-one ever actually needs to duplicate it. Even in scientific computing where people need to be able reproduce each other's results, we're allowed to use each other's tools to help.

So I think the answer is to find out what the real documentation requirements are, then to follow your usual estimation routine to work out how long it might take to fulfil those requirements. On subsequent projects, you can plan for the documentation as part of the project work and for it to take less time because you don't need to reverse-engineer the project at the end.

Answer 4

"all the sudden there's an interest in creating documentation for the project... that's 100% turn-key, meaning that someone with no understanding of anything, would be able to do everything required to duplicate the work done."

This takes a LOT longer than you think!

Don't underestimate this. The type of documentation you are referring to requires a decent technical writer and should not be written by someone who is 'close' to the code. You need an outsider view of the system.

It needs to be written, reviewed, revised. It needs to be tested against the software. It needs to be maintained with the software. Maybe it needs translation. If you don't get it right then it will not be used. It's a significant percentage of the time it took to write the original software.

Answer 5

It all depends is the simple answer I'm afraid, but do not underestimate it.

Start by listing out the docs they want, and sticking a large number beside it, I don't know, say 5 days.

The try and bullet point everything each doc will need, and take it from there.