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.
Re: Parallels Between Software Development and Writing Processes
Subject:Re: Parallels Between Software Development and Writing Processes From:"Susan W. Gallagher" <sgallagher -at- STARBASECORP -dot- COM> Date:Thu, 12 Jan 1995 17:06:15 -0800
George Hayhoe threw the following hat into the ring...
> Dave Taylor aptly observed that there are definite parallels between
> the software development and writing processes. I have noticed the
> similarities as well, particularly the reluctance of both developers
> and writers to do the up-front work which makes delivery of the final
> product so much easier and typically improves the product as well.
[snip a bunch of good stuff]
> Anyone else noticed this tendency in software shops where you've worked?
Is
> this simply a manifestation of human nature, or is there some other
cause?
Back in the early days (mid- to late-80's) I worked in a lot of software
shops that didn't really care what the user *wanted*. There were specs...
Things you *had* to include (like name & address for a customer database),
but what the user *wanted* didn't come in to it at all. I remember one
programmer who got so tired of users who didn't terminate processing
properly that he wrote code that marked every file that "timed out" as
a candidate for deletion! Boy, were those users mad!
I've also seen programs where modules had been added, commented out, and
added again. The program had undergone so many maintenance changes that
nobody really knew what it did. I found maybe 15 repetitive subroutines
in the code.
In software shops that produce programming tools and development systems,
the programmers use themselves as a description for the target audience.
When someone suggested a change by submitting a bug report, it came back
marked "won't fix - as designed".
In my current shop, they go through a really long cycle of planning
documents that get put out on the network for everyone to comment on.
In one of my current projects, they planned for six months. Then when
the coding began, they deviated so far from the prototype I raised
holy h*** and held up beta for two weeks while they fixed it ! :-)
The CEO's comment to the project architect was, "that's what you
get for not getting Sue involved in UI changes earlier!"
I wouldn't dream of starting a book without an outline that I'd
circulated to all the team members for input... But yea, some guys
just can't wait to get started!
Sue Gallagher
StarBase Corp, Irvine CA
sgallagher -at- starbasecorp -dot- com