About estimatiing API documentation?

Subject: About estimatiing API documentation?
From: "Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Wed, 7 Nov 2001 09:01:10 -0500

Mandar Atmasidha wants <<... to create API documentation for a Software
Product. But I do not know how to estimate time for
creating API documentation. Can someone please tell me how to estimate time
for creating API documentation?>>

Use the same approach you'd use for any other project (check the techwr-l
archives on raycomm.com for details, since we've discussed this topic
frequently):
- count the total number of API calls you'll need to document; for each,
you'll need to list the complete syntax, examples, exceptions, known bugs,
recommendations on when to use the call and when to use a different call,
etc.)
- add in introductory material (e.g., introduction, overview of the
programming methods, explanations of the programming environment)
- estimate the time it would take you to complete each topic: writing time,
research time, revision time, interviewing SMEs, getting approval of what
you've written, and so on.
Add these times, and increase the total time by some fudge factor to account
for the fact that no matter how well you plan, unexpected problems will
arise that delay your work or make your work take longer. If the developers
run their operation well, with care taken to create a specification and
stick to it, you might only have to increase the time by 20%; if their
operations are completely chaotic and unpredictable, increase it by 100% or
even more. In any event, if you finish the project far in advance of the
estimated time, consider charging less than the original estimate: not so
much that they think you can't estimate well or that you cheat yourself by
not accepting compensation for your hard work, but enough that they get a
pleasant surprise when the project comes in on time and under budget.

One valuable tip to greatly reduce the risk that you'll encounter surprises:
After you document the first API function, get the client to review it
rigorously while you're working on the second function. Anything they don't
like about your first effort is something you can avoid in all your other
writing. Repeat this process with the new and improved second function and
again with as many additional functions as you require until they stop
finding problems with your work. In this way, you solve problems once rather
than repeating them with each function you document, and establish the
precedent of working closely with the developers to produce the best
possible documentation. Time spent solving problems early is time you save
not having to solve those problems later.

--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html

Hofstadter's Law--"The time and effort required to complete a project are
always more than you expect, even when you take into account Hofstadter's
Law."

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Be a published author! iUniverse gives you: a high-quality paperback, a
custom cover design, and distribution to 25,00 retailers. Join our almost
10,000 published authors today. http://www.iuniverse.com/media/techwr

Have you looked at the new content on TECHWR-L lately?
See http://www.raycomm.com/techwhirl/ and check it out.

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit
http://www.raycomm.com/techwhirl/ for more resources and info.


Previous by Author: A method to organize information?
Next by Author: Electronic document transfer
Previous by Thread: RE/re/re/re Banned words
Next by Thread: FYI: Disintermediate


What this post helpful? Share it with friends and colleagues:


Sponsored Ads