By Richard Lippincott | Guest Editor
For the past few decades, our profession has seen remarkable change driven by advances in technology. An enormous percentage of the work has been in the development, and thus the documentation, of software. As a result, it’s sometimes easy to associate “technical communication” with “software documentation,” and it’s also easy to associate hardware documentation with components and systems associated with computing and networking.
However, large, grand hardware systems were the first subjects of technical documentation. The early 20th century saw the rise of systems such as steamships and railroads, devices requiring detailed instructions for operation, maintenance, and repair. The larger the system, the larger the stack of printed documentation associated with it. Urban legends say that modern aircraft can’t even take off if they’ve got a full set of printed technical manuals on board (not true), or that a large modern ship would sit about a foot higher in the water if all the on-board paper documentation was removed (still under debate).
The presence of technology-associated hardware in our era has brought forth a perception that hardware is smaller, simpler, and less complex than software items that can easily be handled, picked up, and examined on a desktop. It’s probably a fair statement regarding many technology-related components, but it overlooks very large, very complex systems such as aircraft, land transport, oil and gas refining, power turbines, and robotics. These grand hardware systems are truly heavy metal.
We often forget that in order to provide consistency in manufacturing, grand hardware systems require detailed and precise manufacturing instructions. This area of documentation is a little-known opportunity for technical communicators. For example, a modern medical DNA analysis system may be about the size of a commercial microwave oven, and comes with an operating manual that runs about 30 to 40 pages. The manufacturing instructions for the device, on the other hand, may run closer to eight hundred pages. In “Transparent Documentation,” Lonnie Brennan tackles the problems associated with writing these procedures, in locations where your audience isn’t some far away hypothetical user you never hear from but instead is an assembly worker in the same building and who knows how to find you if there’s a mistake.
Ensuring both safety and accuracy is vital with systems where a hardware crash can result in a smoking hole in the ground. Emily Alfson addresses this issue in “Validate Your Content: Quality Assurance Testing for Documentation,” and sets out a plan for checking procedures, tracking errors, and ensuring corrections get made. Although aimed at hardware task validation, the ideas are equally applicable to software.
As technical communicators, we may wonder about but never see our users, nor even know if the documentation is read. But in many cases, our work is absolutely critical to operate and to maintain complex hardware systems. My contribution to this issue, “Why We Write: Tech Docs, Maintenance, and the C-5 Galaxy Airplane,” details how maintenance documentation is regarded as vital to the continued operation of aerospace systems, using as an example one of the largest aircraft in the world.
Finally, Geoff Hart wraps up with a lighter side in Witful Thinking, showing that sometimes really, really big hardware systems result in really, really big failures.
Times and technology may change, new software developments may mean easier interfaces and thus slimmer documentation, but invention also means continued development of grand hardware systems, and development of the documentation for it. When humans finally embark for Mars, operating and maintenance instructions will be on the spacecraft. Somewhere, right now, someone is even preparing documentation for flying cars and walking robots.
Heavy metal, indeed.
—Richard Lippincott
