Linus on Standards

Subject: Linus on Standards
From: Andrew Plato <intrepid_es -at- yahoo -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Mon, 15 Jan 2001 14:38:34 -0800 (PST)

Linus Torvalds said....

> 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.


Previous by Author: Re: Agency warning signs
Next by Author: Re: Where is the ceiling in TW?
Previous by Thread: RE: Textbook writing: don't just blame the authors!
Next by Thread: Re: Linus on Standards


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads