Different Forks for Different Folks

Glyph Lefkowitz 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.

*indeed*!

> 	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
> reality.

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
                     http://twistedmatrix.com/users/glyph





More information about the Squeak-dev mailing list