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: Who dreams up these things? From:"Anthony Markatos" <tonymar -at- hotmail -dot- com> To:wlewis -at- nclogic -dot- com, techwr-l -at- lists -dot- raycomm -dot- com Date:Wed, 29 Sep 1999 09:00:54 PDT
Wendy Lewis said:
Why do you guys insist on arguing with the man (Andrew Plato)?
He is just advocating hard work over bureaucratic cow doodie,
in a pointed, but entertaining way.......
Tony Markatos responds:
I create documentation for complex software products. I see the same old
thing over-and-over-and-over again: design efforts very poorly coordinated.
All other Technical Writers that I know see the same thing. (I do volunteer
work within my local STC chapter and know a lot of Technical Writers.)
A fellow STC member calls this lack of coordination: DAWG (Design-As-We-Go).
No formal processes to ensure that modules are properly partitioned and
integrated; just 'assume this and assume that' and cram this new module into
the existing mess (i.e., the system) any way possible.
The result of DAWG is very predictable: software that is held together with
'chicken wire and bubble gum'(i.e., because design efforts where not
properly coordinated, the creations of the individual designers don't work
well when tied together.)
The end user interface is very poor. Common problems:
1.) Within a given screen, the end user is confronted with a prolifera of
'buzz words' different from those on other screens.
2.) Within a given screen, the end user is confronted with 'buzz words' the
are the same or similar to those on other screens but whose meaning differs.
3.) Screens that ask end user to enter information that, unless they know
the code design or database table design, they don't know -- and have no way
of finding out.
Often, all of the above is then given to the Technical Writer who is told to
"create end user documentation that any high school drop-out can
understand". (What is happening hear is, by default, systems integration is
being dumped upon the Technical Writer.)
Wendy, you equate adding process with adding bureaucracy. This is true only
for poorly designed processes. Not all processes are poorly designed. And
once you have experienced the joy of high productivity and creativity only
possible by working within the confines of effective processes, working
within an 'ad-hoc' organization is depressing.
Also, please do not confuse fast moving workers with hard workers. (This is
a VERY common misunderstanding within the data processing community.)
Einstien said it very appropriately, "Never confuse motion with action."
Fast movers (note: fast moving designers are called hackers) are activity
addicts; always thinking with their hands, they bang away at the keyboard
hour-upon-hour. (Management often loves them because they work through
lunch and put in a lot of overtime.) Yes they generate a lot of motion, but
look at the typical result (see DAWG above).
Hard work in data processing (whether it designing or Technical Writing) is
performing tough analytical work and then switching mental gears to take the
end user into full consideration. Hackers dislike analytical work, I have
yet to see a decent flow chart from one. Hackers dislike end users because
they know that they are incapable of creating software to their (the end