Subject: Re: User-facing applications
From: Chris Devers <>
Date: Wed, 27 Mar 2002 15:04:19 -0600 (CST)

On Wed, 27 Mar 2002, David Fetter wrote:

> On Wed, Mar 27, 2002 at 03:18:50PM -0500, Lynn Winebarger wrote:
> > 
> > Requirements gathering (feedback in the rabid application
> > development model) is like pulling teeth in any case - it's hard
> > work, and users often don't communicate clearly when they do
> > communicate.
> I think you've just demonstrated my point about social groups. 
> It's not that hackers mind doing hard work--ask anybody in kernel
> development--it's that the particular hard work of interacting with
> non-hackers in a productive way is seen as unworthy or repellant.

Or to be a little more charitable, it's seen as terribly unproductive. 
Hacking silicon is easy for this group; hacking people isn't, so stick
withe the area where you have the most traction, right? :) 
> > Usually they can't really tell you what they want within reason
> > (clearly what they want is a telepathically-linked DWIM machine,
> > but that's a useless answer), or even know what they want -
> > except that what you've got isn't it.
> That's not a terribly productive attitude on your part. 

Maybe, but it's a fair assessment of the problem. Getting people to
express what they want can be tremendously difficult. To take a slight
tangent, supermarkets around here [Boston] have started installing
automated checkout lines. In principle, I like this idea -- swiping bar
codes over that laser doesn't look that hard, why not let people do it
themselvees instead of having to let someone else do it for us? In
practice though, the things suck: it's all too easy to knock the system
out of whack, forcing a supervisor to come over and reset it for you.

Why are the systems so hard to use? Partly, because the machines have to
meet some very different requirements, and getting some of them right
(making sure people can't "forget" to scan some things, or accidentally
scan others more than once) makes meeting other requirements (ease of use,
graceful handling of errors) difficult or impossible. But while I can
appreciate that a system like this is more complex than it at first
appears, that doesn't change the fact that it's still a pain in the butt
to use and I'm not going to bother with it until they get fixed. 

Software development is much the same way, of course. I couldn't tell you
what I want in a "good" gui or word processor or almost any other piece of
software, just as I can't tell you what I want in an automatic checkout
lane in the supermarket. It's much easier to recognize what I don't like,
but that isn't necessarily very helpful to the poor engineer that has to
work on the systems. That engineer wants clear specs, and I sympathize,
but people just don't naturally *do* specs. 

As a result, we need to get the system engineers to either start being
more flexible in what kinds of inputs they'll accept -- possibly to the
detriment of the actual systems that they make, which won't be getting
their full attention anymore -- or we need to find translators who can
express human needs in machine terms. That's a very difficult & time
consuming job, and the free software world just doesn't have many people
interested in doing it. That's no surprise when you consider how much more
rewarding it is to make your own mp3 player (or whatever), just because
there one finds a quick, tangible result that can do actual work, even if
the only person that can *make* it work is the person that wrote it in the
first place. Figuring out what someone else wants and how to make it just
isn't as much fun for this demographic...

<cue reference to Norman's _The Psychology of Everyday Things_ />

Chris Devers                      
Apache / mod_perl /