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 Moving Target From:Win Day <winday -at- IDIRECT -dot- COM> Date:Wed, 21 Feb 1996 14:43:53 -0500
I've been following this thread with some amusement. All the proposed
efforts depend on there being in place a formal software development cycle,
even if there isn't yet a formal doc development cycle.
My client doesn't have formal ANYTHING. No standards, no procedures, no
project planning, no formal development cycle. Everything seems to happen
by chance.
Fifteen engineers tailor software to meet the needs of individual customers.
On any engineer's PC I can find at least three versions of all 6 software
packages. And I mean three completely different versions, not three
tailored-for-the-customer versions.
My client is a process control engineering firm. They design, install, and
maintain computer control systems for refineries and chemical plants. Their
engineering services include building customized software packages specific
to each control application or processing unit (right now there are 5
different packages that do different things, and clients get different
combinations of packages depending on their operating units and the control
application project).
The control systems run on different types of computers (Honeywell TDC3000,
VAX, RISC, Bailey, Foxboro), use different flavours of databases that
interface between the online operating system and the control software
(CIM/21, Foxboro, Bailey bridge), and are based on different commercial
simulation packages (HYSIM, ProII). In the past (before they were smart
enough to hire me <g>) my client didn't customize any manuals. They'd
produce one sort-of generic version, and put a disclaimer in the front that
pretty much warned their customers YMMV. The generic versions also had to
include every possible module, whether the control application needed it or not.
Software development generally just sort of happens, usually in response to
a specific customer's need. My client doesn't charge for software upgrades
(we've had many discussions on marketing policies, but this is their
decision). They'll upgrade existing refineries and only charge for the
engineering hours involved. When one engineer does something clever on site
to solve a problem, he or she may or may not remember to tell anyone back in
the office that changes were made, let alone what they were. So the next
poor schmuck engineer who takes over the project doesn't REALLY know what'll
be waiting on the operating system.
I feel like I'm running the Red Queen's race (running constantly just to
stay in one place).
Talk about documenting a moving target!
Win
-----------
Win Day
Technical Writer/Editor
Email: winday -at- idirect -dot- com
