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.
> ANYBODY who does driver development without taking the real world into
> account is a dangerous person. Stacks of papers, diagrams and rules are
> absolutely WORTHLESS if you can't just understand the fact that
> documentation is nothing more than a guide-line.
>
> Once you realize that documentation should be laughed at, peed upon, put
> on fire, and just ridiculed in general, THEN, and only then, have you
> reached the level where you can safely read it and try to use it to
> actually implement a driver.
>
> I'm continually amazed and absolutely scared silly by your blind trust in
> paperwork, whether it be standards or committees or vendor documentation.
Mr. Torvalds makes a very good point about standards, which we as tech writers
could interpret to also mean style guides, processes, documentation plans, etc.
Standards (in this case an standard for IDE drivers) are guidelines, not
commandments. Standards are not reality. Reality is often much dirtier and
foggy than any standard can rectify.
Sure, standards are very valuable. They can help set an environment and define
boundaries. However, it is wise to always be aware of their limitations.
Furthermore, anybody with blind-devotion to a standard is ignoring reality and
potentially dangerous to a project.
This reminds me of a discussion my girlfriend and I had last week. She is
working on a project with some analyst freaks. In every meeting, they keep
bringing up issues that are either irrelevant, insignificant, or simply out of
scope. Their common defense is always that an comprehensive plan must address
all issues. Apparently, "all" in their mind encompasses all matter and energy
in the universe .
It is impossible to address "ALL" issues.
The best plans and standards have lots of flexibility and "wiggle room" built
into them. Incessant over-analysis of insignificant or out of scope issues can
hurt and destroy projects. I watched numerous clients ruin good projects
because one or two planning freaks bungled up every meeting constantly raising
issues. I remember one QA guy who they finally barred from meetings because he
just would not shut up.
Tech writers often fall victim to the same analysis-paralysis. The idea that
the perfect plan insures the perfect project might sound noble and
professional, but at some point the planning must end and the work must begin.
In my experience, the best project use less than 10% of the time and resources
to plan.
Andrew Plato
__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-Based Help with Macromedia Dreamweaver 4 ($100 STC Discount)
**WEST COAST LOCATIONS** San Jose (Mar 1-2), San Francisco (Apr 16-17) http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Sponsored by DigiPub Solutions Corp, producers of PDF 2001
Conference East, June 4-5, Baltimore/Washington D.C. area. http://www.pdfconference.com or toll-free 877/278-2131.
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
