RE: Take this engineer and shove it [Long]

["Giordano, Connie" <Connie -dot- Giordano -at- FMR -dot- COM>]

-----Original Message-----
From: Giordano, Connie 
Sent: Tuesday, May 30, 2000 5:06 PM
To: 'Jim Shaeffer'; TECHWR-L
Subject: RE: Take this engineer and shove it [Long]


Jim,

Some interesting arguments, but I'd suggest (based on your paraphrasing, and
knowing that I haven't read the book) that Mr. Moore does not extend his
analysis far enough.

If the goal of a good software product is to be so intuitive that little or
no documentation is required (which many IT types espouse these days), then
user advocacy, usability and principles of good UI design MUST come into
play when the software is still in the early design stages.  Technical
Communicators, by experience, talent and training, are generally better
suited to these design and communication tasks than programmers.  This in no
way belittles the importance of good code.  But bug-free code is utterly
useless if the UI is bad.  Traditional documentation can't make up for bad
design and bad coding, but it can enhance embedded user information and good
UI, which is the way things are trending in many software applications.

Since I spend about half my time doing UI design work, then my role as
information developer & usability advocate should be valued equally with the
developers'.  I can solve problems during design, that would cause endless
headaches for support, and lots o' extra development time in the next
release.

My two cents (if I was a programmer it'd be valued at about ten bucks)
Connie Giordano.

-----Original Message-----
From: Jim Shaeffer [mailto:jims -at- spsi -dot- com]
Sent: Tuesday, May 30, 2000 4:44 PM
[snip]

Geoffrey A. Moore's new book _Living on the Fault Line_ explains why this
management attitude is rational. No matter how good our documentation is, it
does not provide our companies with a way to 'differentiate their offering'.
Our work falls in the hygiene category, not the core value proposition. 
[snip]
Similarly, most documentation does nothing to differentiate the product when
it is being evaluated by customers. If there is no documentation, that
'stinks'. If the documentation is there, as expected, it is time to focus on
real differentiating factors like speed of execution and ease of use. 
I know, I have argued that documentation is part of the product and can help
with total cost of ownership, etc. This line of argument is inadequate with
most real world customers. Our work, while necessary, doesn't translate
directly to the core value proposition being sold by our companies the way
that good coding translates. 
Caution: I read Moore's book in a hurry and have paraphrased mercilessly.  

Jim Shaeffer
jims -at- spsi -dot- com