Re: Single Sores

[Andrew Plato <intrepid_es -at- yahoo -dot- com>]

--- edunn -at- transport -dot- bombardier -dot- com wrote:

> <<If content is in a constant state of flux, how would putting into a
> single
> source system make life easier.>>
> 
> Because you just put the information into the system as it becomes
> available. If
> it changes, change the information in one place and it changes
> everywhere it is
> used. No need to re-engineer or hand check the created pages for old
> references
> or out of date information. 

You're talking in terms of minor or contained changes. What happens if the
product as a whole fundamentally changes? What happens if you want to
update styles, look and feel, and terminology every few years?  

I agree that any doc set that is in pure maintenance mode can benefit from
such a system. But there are plenty of documents unwritten that need to be
build from square one. A structured system as you describe could become an
impediment more than a benefit. 


> It's nice to be told by someone time and time again that all the hard
> work and
> frustration that has gone into a few years of work (for one project) is
> stable,
> simple, and straight forward. Hyperbole can quickly cross over the edge
> and
> become insult. 

I am sorry if it sounds like an insult Eric. I don't mean it to.  I am
merely trying to say that it is generally easier and more straightforward
to maintain docs than it is to build them from nothing. 

This isn't some "Andrew Wisdom" its common sense. Its a lot harder and
more intimidating to work from nothing than to work from something.

There is also the technology aspects. Some technologies and designs lend
themselves to a higher degree of empiricization than others. 

> Perhaps if you'd listen to the likes of Bill Hall and
> others
> who've shown the merits of single source environments (and jobs that
> involve
> something other than the computer industry) you'd understand. Bill
> Hall's
> examples have been thoroughly detailed and show how complex a task it
> is to
> produce navy documentation and the problems faced and solved by single
> sourcing.

Bill Hall's document is an excellent paper. I read it begining to end. It
is very informative. But, Bill's circumstance is somewhat special. The
assumption that Bill's experiences will work in all environments is faulty
logic. His experiences worked in his circumstances and may work in others.
He even says that in the paper. 

If you are working in an environment that is very similar to Bill's then
by all means, get thee SS. If you aren't, then don't assume lock, stock
and FrameMaker that those solutions will transfer 

> The only thing that is stable about the documentation of aircraft,
> warships, or
> trains is the required output format and organization (but not in the
> rail
> equipment world). The content can change constantly.

"Change" and "government" are two words that just don't fit together well.

I've worked some government contracts in my time. Simply put: they don't
change very quickly. Nothing is done in a rapid fashion.

Which isn't always a bad thing. I suppose if I were going to stand next to
a new cruise missile packed with high explosives, I would want the
documentation process to have been slow and deliberate. 

> Perhaps if the person asking the question was first identified as
> someone trying
> to avoid work then this argument would hold true. Often however, it's
> someone
> with a genuine question looking for guidance.

And I am giving them guidance: move carefully and be smart. Don't sink
your head into SS just because you attended an STC conference and they
said it was required. 

My main point in all this was to realize that SS is not ALWAYS an ideal
solution. Just because something is presented as the "right way" to do
things doesn't mean it is the "best" way to do things. 

> I'm not sure threatened and mocked are the words I'd choose. Insulted
> and fed up
> may be better choices. We should be talking about the weaknesses and
> STRENGTHS
> of various approaches and the words crap and "Penguinheads" or "avoiding
> your
> real job" should never enter the discussion. 

But this is a serious question about SS. Are people implementing SS
because they really need it - or are they doing it to avoid their jobs.  

I love to avoid my job as well. That's why I post here sometimes. I don't
want to face the tepid drudgery of my "real job."  So I agrue about this
stuff because this is considerably more enjoyable. 

Its when people build an entire "movement" as an elaborate work-avoidance
system that I start getting sick. 

I am fed up with technical writers who enter this profession that:

A. Don't want to be technical.
and
B. Don't want to write.

I find these people don't want to write anything, they want to build
empires and cool little "processes." They don't want to become technically
proficient (at least not in the subjects they're documenting), they want
to fiddle with the tool de jour. 

So, I ask: do you REALLY need this? Is this really going to give you
value, or are you doing it just because it sounds fun?  Its a question few
people want to hear because it strikes to the core of their job? Are you
really adding value, or just creating work for yourself so you don't get
fired. 

If all you're doing is avoiding getting fired, then you're not really
adding value. 

> Instead of being derisive onlist, EVERYONE should highlight the things
> to do and
> the scenario in which the approach is best used. Instead of bitching and
> insulting, why not outline how to build a limited single source project
> with
> MSAccess and MSword for example? 

Never reveal what's in the secret sauce, because if you did they'd never
come back for more. 

:-) 

Eric, I am not trying to be derisive, I am trying to refocus the
conversation. How people implement SS isn't the issue here. We could talk
all week about XML this and DocBook that and WebWorks this. That is just a
"my tool is bigger than your tool" discussion. 

I am more concerned, as should all writers, with the larger picture. 
Things like:

1. Does SS add real value?
2. Does it save money?
3. What are the tipping points in useful/useless.
4. Are there less intricate solutions. 
5. How can you accomplish the same things without excessive cost,
training, or development. 
6. Is it better to stick with "manual" methods that may be slower, but
offer a finer level of control over the content. 
7. What about tone of documents? 

You get my point. I am asking bigger questions than "Which XML parsing
tool is more emotionally satisfying."

> Hyperbole about what's bad about something is just as repugnant as
> hyperbole
> about it's virtues. IMO

I get criticized a lot for my use of hyperbole. I find that hyperbole
makes arguments more entertaining, when you accept that the hyperbole is
merely a persuasive tool. 

If you don't like it - I understand. But hyperbole is a part of my
personality, and I refuse to allow any forum - moderated or otherwise - to
completely sanitize my personality. 

"I am not a XML-based single-source solution, I am a free man!" 
           
Andrew Plato 


__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

A landmark hotel, one of America's most beautiful cities, and 
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe.  http://ieeepcs.org/2001/

  +++  Miramo -- Database/XML publishing automation.  See us at  +++
  +++  Seybold SFO, Sept. 25-27, in the Adobe Partners Pavilion  +++
  +++ More info: http://www.axialinfo.com  http://www.miramo.com +++

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