TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
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
---
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.
