🚀 go-pugleaf

In article <bjgP^u#d@twinsun.com> eggert@twinsun.com (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