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.
Subject:Re: Documenting a Mess From:Linda Moore <lhmoore -at- pobox -dot- com> To:TechWR-L <techwr-L -at- lists -dot- raycomm -dot- com> Date:Fri, 12 May 2000 12:05:46 -0700
This is what I would do under similar circumstances, which I might add,
I have been in. Explain to your management that to document this program
is its present condition is going to require more time by a factor of 2,
3 or 4 times as much as it would normally take you, if the product was
well designed. Suggest that they hire a VB guru to test the code to see
how solid it is and to provide an estimate of how long it would take to
modify the current program or redo the program. I can almost guarantee
that this marketing guy has left logic holes big enough to drive a truck
through.
If the current path is maintained, poin out that n addition to the
increased documentation costs, there will also be increased support
costs as well as increase in dissatified customers. One of the benefits
of getting a top VB guru is that even if he redoes the code, it will
take him far less time to complete the task. You can be documenting and
testing behind him so both products will be completed in a timely
manner.
