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: Moving Target , Part 2 From:"Once more into the breach, dear friends..." <engstromdd -at- PHIBRED -dot- COM> Date:Mon, 26 Feb 1996 12:52:07 -0600
Eric:
This is written in response to:
*******************************
I'm having a horrible time getting to the screens because
the development environment database is hosed.
<assorted horror stories deleted>
How many of you have dedicated Training/Documentation
databases for your development projects? We've got a QA
database, a couple of development databases, and the future
production database, which we're using for training.
After implementation, our training database will vanish
and we'll be trying to share with either QA or development.
What do the rest of you do on doc projects--do they set up a
database for you? Who maintains and loads it? Who fixes it?
Suggestions?
*********************************
Two years ago, when I was working on mainframe and mini systems, there
were three full-blown "environments" on each platform: Development, Test,
and Production.
Production was completely clean, and nobody could get into it except the
actual end users and a small number of authorized developers.
Test and Devo were usually created by someone on the development team,
usually by sucking a subset of data down from the Production database.
Test was also kept reasonably clean and consistent, since it was used for
demonstrations, evaluations and testing. As a general rule, we (writers
and developers) could look at things on Test, but weren't allowed to make
changes. However, this was a good place to go for inquiry screen shots and
reporting, because the data was reasonably consistent and the programs
usually worked pretty well by the time they're moved into that environment.
Devo was a madhouse. Almost anyone could do anything, and almost everyone
did. This is where the un-housebroken code lives, you can set up your own
security, and you can enter anything you want. Ironically, it was a good
place to enter "clean" limited datasets of your own, because as long as
you were willing to perform -all- the steps, you could create your own
data.
One of the difficulties in all this was knowing exactly -what- subset of
data had been placed in the Devo and Test environments. Unless you could
find the person who happened to know, you could spend a lot of time in
what often felt like a text adventure--punch a code in, see if anything
responds; try to make sense of the computer's inscrutable reply; punch
another code in...
Skoal,
Doug "I walk the maze of moments
ENGSTROMDD -at- phibred -dot- com but everywhere I turn to
begins a new beginning
but never finds a finish."
-- Enya
***********************************************************************
The preceding opinions and positions are mine alone, and are only
coincidentally related to those of Pioneer Hi-Bred International, Inc.
***********************************************************************