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: Dev. Cycle and the Manual From:Ben Kovitz <apteryx -at- CHISP -dot- NET> Date:Thu, 3 Jun 1999 14:50:35 -0600
John Posada replied to Lief Erickson:
>> > Is it possible to have a user's manual near
>> completion at the end
>> > of the requirements phase of development?
>
>HAHA!!! I've rarely seen a Users Manual near
>completion at the end of the code writing phase of
>development, let alone at the requirements phase.
>
>Then for that matter, I've rarely seen the Code near
>completion at the end of the code writing phase.
>
>You know how I knew that the software for my project
>wasn't going to make it on time? The delivery date was
>supposed to be June 1st (no make that April 1st, no
>make that Dec 31st...).
>
>What's today's date?
Stephen J. Owens said something very relevant here:
> The closest thing to software project management is any large
> engineering effort to design and engineer completely new systems
> to address completely new needs. Not simply building/designing a
> VCR or a cellular phone from scratch, but designing a new kind of
> video recording and displaying technology from scratch, or a new
> kind of communication system from scratch.
No one would imagine that those sorts of projects could possibly
run on precise schedules known even before the requirements are
written. What is really strange, then, is that the software
development world keeps kicking itself for not being able to
estimate and schedule precisely.
I recently picked up Tom DeMarco's book _Why Does Software Cost
So Much?_ It's an interesting collection of essays--quick,
stimulating reading. DeMarco says that making software is
*research and development*, not factory-work. About why
software costs so much, he says that actually it must be one of
the greatest bargains of all time, since so many people are so
eager to pay big money to have more of it written.
We keep knocking ourselves for failing to meet some extremely
idealistic standards, but we really are a very successful field.
