NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/groupwar/715

Text File | 1992-08-14 | 3.7 KB | 64 lines

Newsgroups: comp.groupware
Path: sparky!uunet!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!UB.com!athertn!news
From: [e-mail] (Scott L. McGregor)
Subject: Re: Article - Behind the Terminal
Message-ID: <[e-mail]>
Sender: [e-mail] (News Administrator)
Reply-To: [e-mail]
Organization: Atherton Technology, Inc.
References: <bjgP^u#[e-mail]>
Date: Fri, 14 Aug 1992 21:59:40 GMT
Lines: 51

In article <bjgP^u#[e-mail]> [e-mail] (Paul Eggert) writes:
> Similarly, it's a mistake to criticize system analysts who don't
> consciously apply social theories to the problem of analyzing computing
> systems.  Analysts omit social context when it's convenient, but that
> doesn't mean they're unaware of the context -- it only means that they
> have better things to do than write lengthy dissertations on subjects
> that are obvious to their audiences.

I agree with Paul Eggert that many systems analysts do indeed consider social
context, even when they don't explictly comment on this in their documents.
I've noted that several very experienced designers are exceptionally astute
about social context, and their designs reflect that even though they never
comment on it.  In fact, when questioning such designers you often notice that
this focus on the social aspects is so fundamental and innate that they don't
often think about the fact that they are doing this automatically.  Only,
detailed questioning reveals that indeed these analysts do consider social
context and even have a rich experiential base to draw good conclusions from.

Unfortunately, the fact that these considerations often aren't made explicit
does tend to hide them from more junior designers.  Usually these aren't the
intended audiences--experienced designers often write explanations for others
who are assumed to be equally expert.  Sometimes this is the wrong assumption,
but even where it is correct, we too often ignore that in many cases such specs
are given to unintended 3rd parties who are being "apprenticed".  The result is
often because these considerations aren't explicit the apprentices often never
think about them and don't learn to apply them to their projects as they gain
more experience.  More worrisome, to me at least, are the legions of junior
designers who conclude that such sociological concern are inappropriate or
irrelevant to "hard science" and computer engineering because they don't see
them discussed in the expert's publications. Their comments are often
recognizable by claims that nontechnical concerns "shouldn't matter", or that
"logically equivalent" solutions "should be equally acceptable to users."

This is  the truly unfortunate problem and accounts I think for the constant
re-discovery in groupware applications producers of the social and economic
balance requirements which Grudin has often cited.  It is unfortunate that
without the seemingly obvious  explanations we seem to perpetuate this lack of
understanding among somejunior analysts.

In summary, I agree with Eggert that not all system analysts should be painted
with the same broad brush.  At the same time, I agree with Kling that it not
uncommon for some designers, especially inexperienced ones (who probably
outnumber the experienced ones) to exhibit an apparent insensitivity to these
issues which limits their successful introduction of new technologies. Kling's
new approach will probably not be particularly rewarding to those analysts who
already automatically apply social models.  It remains to be seen if it will
open the eyes of those who currently do not.  This should probably be the test
to retroactively evaluate its success.

Scott McGregor