Glyph Lefkowitz glyph@twistedmatrix.com wrote: Although I've never worked in the medical industry, I've worked on custom vertical-market software. This stereotypical cry of frustration, often idealized into the anguished cry of the virtuous user against their technocratic opressors, is equally often just a declaration of resistance to change. "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".
For what it's worth, my local GP's computer system flatly refuses to let them spell my name correctly. My name is "O'Keefe". But their system will not allow anything except letters in names. So they try to enter "OKeefe" which at least lets them get the capitalisation right. But the system knows that names have exactly one capital letter, at the front, and won't let them do that either. Whoever designed the software had not taken the trouble to look at a telephone book.
Then there was the court case where I was an expert witness. The software was (a) 3 years late (it was supposed to take 6 months), (b) seriously buggy, (c) atrociously slow, and (d) required the sales-clerk to enter the same information on two screens because the designer KNEW that purchase orders and invoices HAD to be different forms, even though the customer had stated over and over and over again (with examples aplenty) that their parent company required them to use a single form.
Then there's the electricity company (Contact Energy) that sent me, as the bill for December 1999, a repeat of the May 1999 bill, whose computer *would not let the customer service operator, or her supervisor, or his supervisor, correct the mistake.
Using technology to improve one's job performance or enjoyment does not mean familiarity, it doesn't mean that the software engineer ought to know exactly how the job used to be done; in fact, if the net result of buying an expensive piece of software is that the job gets done in exactly the same way it was done before, but with a $1000 computer and $500 worth of software, why would ANYONE buy business software?
Basic usability fact 1: the people who make the purchase decisions are not the people who have to use the software.
Basic usability fact 2: the offical work processing rules the analyst is told about are a fiction; the way things _really_ work is different.
Basic usability fact 3: mistakes happen; it is important to have reasonable facilities for correcting them.
A classic book on data quality estimates the proportion of bad fields in real working commercial data bases as about 20%. The figure for the NZ Police computer system is apparently comparable. Of course you can say "operator error", but _why_ are operators making errors at such rates and _why_ is it so hard to correct 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?
If the fellow who designed that "piece of crap" didn't know anything about how they do their jobs, why did they buy the software?
See basic usability facts 1 and 2.
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 was reading a book about quality recently (I'm really sorry I can't remember whose, but perhaps someone will remember the anecdote). The author claimed that this really happened:
Manager comes to tech support and asks for a laptop computer to take to a weekend conference.
Technician explains that they're all out except for one, which needs repairs.
Manager insists on having it anyway, then complains that it's too heavy.
Light goes on in technician's head. In manager's presence and with manager's informed consent, technician removes battery pack.
Manager goes away satisfied.
Sometimes a computer is just an executive status symbol.
On Sunday 29 April 2001 21:36, Richard A. O'Keefe wrote:
Glyph Lefkowitz glyph@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.
squeak-dev@lists.squeakfoundation.org