RE: [SPAM] Moving upstream

Subject: RE: [SPAM] Moving upstream
From: "Joe Malin" <jmalin -at- tuvox -dot- com>
To: "Beth Agnew" <Beth -dot- Agnew -at- senecac -dot- on -dot- ca>, "TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Fri, 19 May 2006 10:36:09 -0700


As a technical writer and sometimes product manager, I have sometimes
helped improve the product. I grant you that some companies may still
allow or even foster an attitude that only engineers are welcome
"upstream". The biggest and best ones I know of in the Silicon Valley do
*not* have that attitude.

I think the intensely competitive nature of the software business has
led to problems in the design process. The engineers are pressured to
release the product as quickly as possible. Their first goal is to get
the features to work. User testing, systems thinking, documentation, and
even bug fixing is all secondary.

The pressure comes from everywhere. Competitors are always out there
seeking an advantage, investors want results yesterday, customers are
begging for new features. Only the best, most sagacious product and
engineering managers can resist all these challenges. Also, in big
companies one gets pressure from other engineering groups!

The modern concept of computer software as something that you buy
yourself off the shelf in a store, install yourself, learn yourself, and
use yourself almost immediately is perhaps 20 years old. It is a radical
departure from all previous experience with computers.

When I started in the business, software was something a company wrote
for its computers. The only real exception was IBM. By the time I left
mainframes, a *few* companies were selling software, but they still
expected to install it and configure it for you, and then train you to
use it. This attitude continued well into the minicomputer stage.

The modern idea of software dates from some time after the introduction
of the IBM PC. One can not expect any real change in the way that a
computer "works" in this short time, given its prior history. Perhaps
now is the time for change?

In some sense, open source software is a step backwards. Plenty of
powerful stuff, but not very useful unless you know lots about
computers. Instead of making *computers* smarter, we are trying to make
*users* smarter. Sadly, I think this is often the way technology works.
We haven't figured out a way to get information into computers by
writing, so we now expect everyone to know how to touch-type...

And that is why software doesn't work the way we think it should. The
people who write it are in the culture that believes that it *does* work
the way it should; they don't worry all that much about people who
aren't in the same culture.

Joe Malin
Technical Writer
jmalin -at- tuvox -dot- com
The views expressed in this document are those of the sender, and do not
necessarily reflect those of TuVox, Inc.

-----Original Message-----
From: techwr-l-bounces+jmalin=tuvox -dot- com -at- lists -dot- techwr-l -dot- com
[mailto:techwr-l-bounces+jmalin=tuvox -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf
Of Beth Agnew
Sent: Friday, May 19, 2006 10:38 AM
Subject: [SPAM] Moving upstream
Importance: Low

In a reply on the Troubleshooting? thread, Geoff Hart noted:
"Why leave to chance something you can automate for the user? For that
matter, why not test whether the user created a known problem after each
step, and if so, pop up a note telling them how to fix it?"

Why not, indeed? These and a hundred other good ideas for making life
better for the user are things best handled at the analysis and design
stage, rather than in documentation. Unfortunately, this upstream
position is often a place where techwriters are not welcome. The few of
us who successfully insinuate ourselves into the design process find
that we can make useful and cost-effective changes that improve the
product long before it gets to the QA or Customer Support Complaint

WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today!.

Doc-To-Help includes a one-click RoboHelp project converter. It's that easy. Watch the demo at

You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit for more resources and info.

Previous by Author: RE: Documentation there really such a creature?
Next by Author: RE: in order to - and localization
Previous by Thread: Re: (no subject)
Next by Thread: Is there a formal name for an inspection process

What this post helpful? Share it with friends and colleagues:

Sponsored Ads