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: Now here's an idea... From:Len Olszewski <saslpo -at- UNX -dot- SAS -dot- COM> Date:Tue, 22 Feb 1994 09:58:52 -0500
Eric Ray sees something intriguing on another list:
[...]
> >write the user's manual, in as much
> >detail as possible, before starting the design
> >of the tool. You can't be influenced by the inner
> >workings, which you don't know yet, and you can pass
> >it around for criticism.
> Now, doesn't this sound familiar? Takes our conclusions
> a couple of jumps farther. Actually, it sounds like a
> reasonably feasible idea, within reason. I haven't met
> many programmers who would admit to not being able to
> code anything.
> Comments?
Around the Raleigh area, an IBM branch (or something) was doing this a
few years back, I think as sort of an experiment.
As a technique for developing software, this sounds alright; you write
the documentation for a product that doesn't exist, use the document as
the spec, and code it. To work:
- the writers have to be pretty good designers, and account for
the software and human factors sides of things
- the writers have to have some problem domain expertise, you
would suspect (e.g. - some accounting experience for an
accounting product, some statistical experience for a stat
product, and so on)
- you need respect and rapport between writers and developers,
including communication and the ability to compromise
- you would need some mechanism to add improvements to the
product if the opportunity was there (this is why you need
communication, in order to find out if improvements were
indeed possible to the original spec, and to take advantage
of them if they were)
- just as you have tech review of the draft document by
developers, you would need tech review of the draft document
*and the product* by the writers and developers *together*.
I've never worked in a situation like this before. I don't know if I'd
bring the right mix of skills to the process. But for certain areas
where I have some expertise, I'd be interested in trying it. Somebody go
tell my boss for me, ok? 8^)
|Len Olszewski, Technical Writer | "Truth does not stick to glossy |
|saslpo -at- unx -dot- sas -dot- com|Cary, NC, USA| paper." - William Horton |
|---------------------------------------------------------------------|
| Opinions this ludicrous are mine. Reasonable opinions will cost you.|