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: Is it just me? S/W doc question From:Phillip Winn <pwinn -at- S7 -dot- COM> Date:Thu, 29 May 1997 15:54:21 -0500
At 08:34 AM 5/30/97 +1200, you wrote:
>Does anyone out there have a system the WORKS?
Sure, but it requires a little more work out of the Techwhirler, and also
requires that the Techwhirler be a little more technical than average, but
here is what has worked the best for me in the past:
At one company, the programmers' work was completely documentation-driven.
That is, the documentation was written first, then the engineering was done
based on the documentation. The screens were written to match the usually
detailed drawings, the inputs were arranged according to the paper mockups,
and the underlying business logic was described in the documentation
clearly so that there was little room for error. Occasionally that was
documentary material that was needed to ensure the programming staff stayed
on the straight and narrow that wasn't appropriate to show the end user,
and those sections of the documentation were marked up as for prgrammers only.
It was beautiful, but not easy to implement. We did have some minor
difficulties with programmers who felt that they knew better than the
designers (they were separate groups, with a little overlap), but we
educated them to make changes on their own without working with the
The interesting thing about this system is that is was driven by the
engineering side in response to the holy grail of software engineering
books, "The Mythical Man-Month". The more interesting thing about this
system is that it works.
I've been a designer, a programmer, and a techwhirler in that company, and
I liked each part of that approach. I'm curious to hear of any other
companies that might have tried the documentation-driven approach and what
the results were.