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: The Never Ending Saga: Screenshots From:"Tom Johnson" <johnsont -at- starcutter -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 7 Jun 2001 15:10:40 -0400
Eric,
You are mostly right. A lot can be done before the software is finished IF
the coding is done to the specs and the specs exist in the first place. Most
of the software I've worked on has not been stable enough for that to work.
The advantage to working on hardware, like trains or CNC machines, is that
the engineers have to get it very close to right the first time around. If
they don't, the project won't bolt together. I get to work in both worlds
and there is no question that the software undergoes more revision and
reworking than the hardware. Why? Because they can change it at a whim. Code
is cheap compared to iron. It is a lot harder to rework a casting than it is
a block of code and that makes programmers much more likely to refine the
code until the very last minute.
So, until programmers learn how to refine the specs to near perfection, like
mechanical engineers have been learning for a couple hundred years (my
reference point is roughly placed somewhere around the start of the
industrial revolution), code will change rapidly. Programmers have only been
doing this for about 55 years. Software is still a maturing industry. Is
there an incentive for coders to adopt the methods that mechanical engineers
have learned over the years? It will probably only happen in software that
lives depend upon (things like the space shuttle or life support systems)
where the function is clearly defined beforehand. Those kinds of
applications require tons of red tape to deviate from the original plan and
programmers have the incentive to stick to the script.
> -----Original Message-----
> From: bounce-techwr-l-60147 -at- lists -dot- raycomm -dot- com
> [mailto:bounce-techwr-l-60147 -at- lists -dot- raycomm -dot- com]On Behalf Of
> edunn -at- transport -dot- bombardier -dot- com
> Sent: Thursday, June 07, 2001 1:42 PM
> To: TECHWR-L
> Subject: The Never Ending Saga: Screenshots
>
>
>
>
> A huge advantage is if some kind of source for the screens is
> available,
> documentation can be finished before the program is
> functional. So unless your
> group is adding functionality, buttons, etc. at the last
> minute and not just
> trying its best to make the software usable and work according to
> specifications, there is actually very little need for
> functional software to
> write the manuals.
>
> Eric L. Dunn
>
>
>
Tom Johnson
Technical Writer
Elk Rapids Engineering/Star Cutter Company
231-264-5661 voice
231-264-5663 fax
Work johnsont -at- starcutter -dot- com
Personal thomasj -at- freeway -dot- net
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
Sponsored by Cub Lea, specialist in low-cost outsourced development
and documentation. Overload and time-sensitive jobs at exceptional
rates. Unique free gifts for all visitors to http://www.cublea.com
---
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.
