Don Beaton pased along this item from slash.dot: Present writing as an engineering problem by MarcusQ. His transposes engineering analysis over to the writing process:
1. Top down design.
2. Checking your facts.
3. Failure mode analysis.
4. Dependency analysis.
5. Optimization.
6. Structured testing.
The only one I object to is #1: Starting with an outline and working out the details is the normal way of tackling an engineering problem.
The assumption is being made that I, as a writer, know the outcome ahead of time. When writing a new book -- even on a sterile topic like CAD -- I don't know how it will turn out, because CAD is software that's written by humans who make mistakes (bugs, strange implementations of commands, inabilities inherent in the sw, etc). Unlike in fiction, where the author controls the plot, in non-fiction the facts control the author.
Even in brief blog entries, the outline changes as thoughts written down generate new notions (such as this sentence.)
One item missing from the list is the team of copy and technical editors, the second sets of eyes that check to see if the calculations (writing) are correct.
Comments