Different Forks for Different Folks
glyph at twistedmatrix.com
Mon Apr 30 16:32:44 UTC 2001
On Sunday 29 April 2001 21:36, Richard A. O'Keefe wrote:
> Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
> "This software engineer knew nothing about how we do our jobs!" can really
> mean "I knew how to do this job with yellow sticky notes, and the
> interface doesn't remind me of the yellow sticky notes I know!"
> It can also mean "This software engineer WASN'T ALLOWED to talk to users".
Very true. I've had that problem too. Although I agree with the other stuff
you've said here, that's probably the nastiest problem directly relating to
the design of software.
[points about court case and electric company elided]
> Basic usability fact 1: the people who make the purchase decisions are not
> the people who have to use the software.
I am not sure how our society got to this point, but it seems like the people
who actually know what they are doing have very little say in how it gets
done. This has repercussions that extend much deeper and wider than software
though. Something much like the story of your court-case happened recently
to a friend of mine with a general contractor.
> Basic usability fact 2: the offical work processing rules the analyst is
> told about are a fiction; the way things _really_ work is different.
Keeping this in mind as an analyst is dangerous, though; if it encourages one
to find out how things really are by talking to people, that's good; but
attempting to logically extrapolate something that is different from the
contract is certainly not.
> Basic usability fact 3: mistakes happen; it is important to have
> reasonable facilities for correcting them.
> Of course, software in those situations is a
> tool, and using a tool requires learning. In my experience, a surprising
> number of people are not interested in or actively resistant to learning.
> Why _should_ someone be interested in a tool which was imposed on them?
Well, if you're employed by a company where arbitrary, poor decisions are
made on a regular basis without your input, software should be the least of
your worries. If your job hasn't driven you to quit yet, then each tool
you're presented with is something that you should attempt to learn; I know
that pathological examples exist, but in my (admittedly limited) experience,
at least *some* software is better than the pencil-and-paper alternative ;)
> I imagine it's not free. If someone ELSE bought the software
> (not the RN you spoke to), perhaps there are different ideas
> about how an RN does, or should do, their job.
> And it was the software vendor's job to find out which one best fits
I wouldn't want to be a software vendor to a company where
> [...] a computer is just an executive status symbol.
It provides a catch-22 to software authors. If the only way to sell your
software is to please management, but that runs counter to the interest of
actually making good software (software that models the way the job should be
done in reality, allows correcting of mistakes, etc), what should one do?
A horrific anecdote from me: one company that the place I used to work did
contracting for had a policy that no employee could correct mistakes in the
database. The senior managers didn't trust anyone to actually change the
data once it was entered. This required an elaborate permissions system
which was quite expensive.
Once it was finished, since data entry mistakes were relatively frequent (as
you mentioned, they always are), there was incessant complaining on both the
managerial and employee side about what a pain it was to have to go talk to a
senior manager every time someone made a typo. Although this problem was
routinely blamed on the software, the real issue was a lack of trust between
the management and their employees, and only this custom software enabled
them to be so constantly and consistently watchful and untrusting.
How do you sell software to people like that? In this case, they actively
*wanted* to make the data input process user-hostile. It's a bad way to
write software, and unpleasant for all users to deal with, but it's the only
way to get the business.
______ __ __ _____ _ _
| ____ | \_/ |_____] |_____|
|_____| |_____ | | | |
@ t w i s t e d m a t r i x . c o m
More information about the Squeak-dev