Subject: Re: User-facing applications
From: Lynn Winebarger <>
Date: Wed, 27 Mar 2002 16:58:38 -0500

On Wednesday 27 March 2002 15:34, 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.

     The reason it's hard work isn't because of the interaction per se, it's 
because  of the fact below [also, it's not hacking, which is what they really
want to do, remember?]:

> > 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.  Those
> people are at least as much a part of the reality of making software
> as the machines on which the software runs.

     It's a fact, not an attitude.  Just because someone can recognize a 
problem doesn't mean they can design a (good) solution. 
   One of (if not the only) reason RAD is a "good" dev model is that it 
presents UI options early and often.  By the way, the hard work is a two
way street - the typical user for the type of app you're talking about will 
view testing it as hard work.  It also depends on the category your free
software is in: (a) something completely new, or (b) something similar to
another already existent application.
    When you develop something for a company in-house, you're pretty
fortunate - you know who your users are right off the bat, and they have
a built in incentive to spend some time working with you -- and even then
you might have some incalcitrants who expect you to read their minds.
    Now, in the cases you're talking about, your users are everywhere and
nowhere.  In case (a), you have to convince someone that what you're doing
is useful enough for them to spend time testing, warts and all - ie someone
ahead of the curve.  In case (b), you have to convince someone to spend
extra time testing your software when (i) most of them consider just using
the software "work" , and (ii) they've already got something that does the
    So, in both cases, you're looking to recruit (at least, restricting to
volunteers)  atypical typical users.  This is naturally going to skew your
results towards power users, but it's better than no input at all.  To get
a really good sense of what's needed, you'll probably have to pay for the
time and effort of some typical typical users.
     We could also relate this to ESR's "scratch your own itch" fs
development theory, since in that case the developer _is_ the atypical
typical user. 

> Aha!  So, one avenue of approach to this would be along the lines of
> gathering test subjects...hmmm...
    Naturally.  You want to test the empirical yet vague question: "Is this 
useful to you?".  How else would you go about it?  [ Of course you'd
also like an true answer to "What would be better?", but if you _expect_
such an answer, you're likely to be disappointed.  Also, if you act as 
though the user _should_ have such an answer, you're likely to get some 
resentment ].

> How is your theory different from mine?

    Mine gathers people into functional groups, rather than social ones.
Hackers are hackers because they love their toy so much they make new
ones (I think that applies to more than software hackers).  The "typical
user" is entirely different - they interact with the computer differently 
because they see it differently (it's a magic box, remember).  They 
probably don't want to spend their spare time fiddling with it.  Yes,
there's a spectrum, but I believe the mass of humanity is going to fall
towards the "typical user" end I've described.  They're simply interested
in other things in life.  In some cases they may even be antagonistic
(improvements in technology often lead to elimination of jobs - healthy
perhaps in the long run, but locally painful).   The reason it's difficult
to find testing candidates isn't that it's hard to interact with them
(though individual hackers may be socially dysfunctional), it's because
the kind you need are somewhat rare.
   The social grouping is symptomatic of the functional grouping, rather
than identical to it.