Documentation estimates for undeveloped software

[John Posada]

This is a case of submitting a figure to shut someone up and place a
checkmark in the "received" column. You realize that if it turns out
to be anywhere's near accurate, it will be pure dumb luck...I mean,
how does how quickly a developer massages a piece of code correlate
to how quickly you can document it?

> using 50% to capture the QA/testing.  I am inclined to the same
> figure.
> What would you use.  Thank you.

If they truly want an accurate number vs "a" number, I would use the
process that I use for any project plan.

I know it takes me a day to write, verify, and polish half a page of
content. With minor exception, I also chunk my content into an
average of a half page per topic. If it's a large topic, I chunk it
into multiple half-page topics. Therefore, when I produce an outline
with every topic I can anticipate, I can count up the number of
topics and multiply by a day each.

This method has proven to work for me. Maybe it wouldn't work for
you. However, instead of pulling a nice round number out of the air,
if you want the number to have credibility, it must be based on a
proven process, not a throw of the dice.

John Posada
Senior Technical Writer

"So long and thanks for all the fish."