Re: [Gnu-arch-users] "tla commit" generates a patch-set even if there are no changes

[Tom Lord]

    > From: address@hidden

    > On Mon, May 17, 2004 at 04:40:12PM -0700, Tom Lord wrote:
    > > There is a much, much better substitute for counting posts on g-a-u:
    > > the "trusted lieutenants" system.

    > The problem with trusted lieutenants with _user interface
    > issues_ is that they know enough not to do the thing that
    > irritates newbies.

I don't think you got my point.

The people I pay most attention to, UI-wise, include those who work
with newbies off-list and those who read many messages from newbies
here.   In general, they're people who are aware of and thoughtful
about the trade-offs in UI-decision making between imperfect emperical
data about user experience, a priori reasoning about "what makes
sense", and, yes, the perspective of experienced users.


    > The real answer is to perform HCI studies -- put a whole
    > bunch of people in a room and let them loose on tla
    > and watch, without interfering. (and weep).

What a huge amount of crap.   I'll spare you the 10 page rant but the
story behind that mistaken belief of yours is telling:

You get (say, around the 1980's) a tiny bit of actually non-vacuous
research publications from the nascent academic HCI field --- the very
first inklings of a vague groping towards a methodology for
_measuring_ usability _objectively_.  Whoa!  Somebody call me a
time-study man, quick!

As part of the foundation of a new academic field -- bravo!  Brilliant
stuff.  Keep it up.  Call us (in industry) in about 40 years, please.
Until then, let's meet for coffee with our cog-psych friend and talk
about logic and conceptual models gesture-space and have fun trying to
make some systematic sense out of it all.

But as a real, practical breakthrough?  It ain't there yet -- not by a
long shot.  It's at the stage of being a little better than the I
Ching or a cut-up of Programming Patterns aphorisms -- but not a _lot_
better.

Meanwhile -- the business world.  Contemporaneous with that academic
work, viola le Macintosh.  Here we have something very confusing and
hard to interpret --- an obvious breakthrough in design, and yes, no
shortage of methods employed by the designers that _resemble_ the
academic usability studies (superficially).  But, really, just some
good old school, black magic designers who worked out their own little
studio culture with all the attendent shared ideas and aesthetics.
That's the deep truth --- those guys just formed a community and hit a
groove.  They rock(ed?).

You then get a couple of decades of software development managers,
like so many medieval alchemists, trying to repeat or mimic that
success.  Hiring 'spensive consultants to come in and run HCI studies
of the sort you describe, spending 10's of K or more, just to report
that "Oh, the menu categories are getting jumbled" or "use of the
middle mouse button is inconsistent in a way that bugs users" or "use
of the middle mouse but is too consistent in a way that bugs users"
--- stuff that any attentive hacker (or user) could have figured out
from first principles if they sat down and thought about it for a few
days.   The end result being, as often as not, something like a
hyperactive and interruptive talking paperclip on my desktop.

So, in that business world, you have lots of money flying around and
very largely being wasted on these kinds of studies (or just on
consulting sessions from gurus who supposedly carry the torch).   And
you have never-can-blush managers who will pimp for this little
cottage industry of alchemist bullshit because, if they didn't, they'd
have trouble explaining why they hired them.   And because the
propogation of technological fact through the software industry is
_so_ slow that bad decisions tend to be divorced from their
consequences by years....

It's the trickle-down effects of that absurd dynamic that bother me.
It's when you get folks like you, arguing on this list, where there's
no danger whatsoever of any of us running off to hire an HCI
consultant, yet here you are, arguing for such methodology,
predicting the results to spare us the expense, and citing imagined
results of non-performed studies using a pseudo-scientific methodology
to test quasi-hypotheses of a net-yet-science and, best of all,
_interpreting_ your (out of thin air) results to draw social and
economic conclusions!

And to think that, indirectly, all of this is because Andy Hertzfeld
or someone once casually remarked that "Oh yeah, a couple times we
gathered a bunch of clerical workers to test the word processor and we
got a lot of clues by watching them."

By in large, SCM tools are things that programmers work with for a
very long time.  Their experience as raw newbies constitutes a
diminishingly small fraction of their overall experience with arch.
Nearly any annoyance made to experienced users on behalf of newbies is
a net loss.

Typically in these conversations people start arguing about the
importance of the newbie perspective for _adoption_.   "If you don't
screw experienced users," the reasoning goes, "new people will just
take one look at arch and run away."

But the actual facts of the matter are:

  1) We do plenty for newbies --- just under the constraint of 
     _not_ screwing more serious users.

  2) Adoption of programmer tools by programmers seems to be different
     in nature from adoption of application programs that
     non-programmers casually use.

     My hypothesis (which seems to be working out ok) is that 
     if you are lucky enough to start off with a small core of users,
     each respectable in their corner of the world, who happen to
     believe in arch and find it a good tool -- that their endorsement
     will lead a next generation of users to get over any initial
     hurdles and join the fun.    And then recursively -- so it
     snowballs a bit.

Without reference to any specific UI issue but just as a general
observation:  managing source code, especially managing branches and
revisions and merges of source code, is hard.   It's harder than they
teach you in college.  It's harder than you experience doing exercises
in college.   It's harder than you you experience doing low-level
programming jobs.   It's a subtle art and mastering it is a healthy
percentage of what it takes to be a good programmer.

Sometimes I have the impression that newbie complaints about arch (or
any of several other systems, for that matter) are really saying "I
wish it was easier to manage source code" --- but there's nothing any
tool at all can do about that.  Einstein is said to have said
something like "Things should be as simple as possible -- but no
simpler."   That applies to UIs, too.

When this plays out in something like a discussion about a "--force"
option for commit, those who would make oversimplifications easilly
fall into a trap of thinking about just one or two out of dozens of
plausible use-cases.   For their particular case, the option is a win
-- for many others, a lose.   Confronted with this, they start
handwaving.   "My case is the common case!   My case is the newbie
case!   Count the posts on g-a-u:  the majority is more concerned
about my case!"

Yeah, well -- the fact is that the arch project is doing pretty well
so far in ignoring such noise.  We have an informal and unorganized
subset of the community who have proven that they are thoughtful about
as many valid UI perspectives as they can figure out, about the
"logical structure" of the UI, and about the true nature of the SCM
problem.  This informal group makes a pretty good filter for 3rd party
ideas and a pretty good source of original ideas.

Any perfect design for something like arch is going to have properties
that tick off this or that subcommunity of users.   Ultimately, that's
ok:  it means that using arch well involves an element of skill or
craft;  it means that learning to use arch well means learning how to
minimize the impact of those properties.   That's hardly surprising to
me -- my opinion is that that is intrinsic in the nature of the SCM
problem space.


    > Meanwhile, newbies are lining up to suffer.(1)

    > Matt
    > 1. there I go with one of those unsubstantiated claims.

Yes, you do.  It's a defect, really.  We love you anyway.


-t