Jump to content

Check out our Community Blogs

- - - - -

The Ivory Tower of Programmers

Posted by gregwarner , 01 April 2011 · 476 views

I used to work as a customer care representative for a pharmacy, providing technical assistance to the pharmacists for their pharmacy and point of sale systems. There was a reoccurring problem in the point of sale software that would cause the system to lock up. (This system was AJAX-based and was developed in-house.) Whenever the software would lock up, the pharmacist would usually close out the browser and try it again. However, due to the way the software was written, this would cause pending transactions to run through the credit card processor, but not our system. So the customer would get billed, but our system wouldn't show it. The pharmacist would run the transaction again, and I would get a call in a couple of days because the customer was billed twice.

I brought this problem up with our programmers many times, and each time they would respond with indignation, "What those idiots are doing is going up and hitting the red X on the browser. Every time they do that, it messes up the transaction. They need to read the prompts to find out what's going on instead of ignoring it." I never got a straight answer out of them, and so for many months, I wrestled with this issue.

When I was an installer and trainer for a medical records system for nursing homes, I ran into similar problems with the software. The development company that wrote and maintained the software was in a different state. The developers had never spent time in a nursing home, were not nurses, and did not know the nursing world. They relied on a single nurse consultant, who was not computer savvy, to determine how the workflow of the application should work. Needless to say, my days as a trainer were often just as frustrating as the nurses probably were when the system would inexplicably break.

John McCarthy (the inventor of Lisp) said, "Program designers have a tendency to think of the users as idiots who need to be controlled. They should rather think of their program as a servant, whose master, the user, should be able to control it. If designers and programmers think about the apparent mental qualities that their programs will have, they'll create programs that are easier and pleasanter — more humane — to deal with." "The Little Thoughts of Thinking Machines", Psychology Today, December 1983, pp. 46–49.

No quote better embodies the problem I was facing with both programs. The issue wasn't with the users, it was with the programmers. They could not be bothered to redesign their programs to optimize them for the workflow of the users who would be using them.

Instead of saying the pharmacists stupidly close the browser, the programmers should have understood that their job was to create a tool that would make the pharmacist's job easier. If the program had apparent hang-ups from time to time, it should have been rewritten to postpone the credit card transaction until later in the workflow so that when the user closes the browser, it doesn't duplicate the transaction. Moreover, the prompts needed to be more visible if that was truly the issue. The programmers needed to genuinely listen to the pharmacists' complaints instead of treating them like idiots who couldn't use the software correctly. Likewise, the programmers of the medical records software should have gotten down off their ivory tower and spent some time learning what the nurses are used to dealing with concerning record keeping so they could code more toward their specific needs.

Programs and their interfaces should be designed with intuitiveness in mind. My current job is head of development for a medical records system for a children's clinic, and I am spending as much time as possible in the thick of it--meaning I am in the clinic, talking with the clinicians, and learning how their day-to-day operations are run.

When we get this system developed and perform the conversion from their old paper system to paperless, I want the transition to be as smooth as possible. My goal is that, when the clinicians sit down in front of the computer and launch our application for the first time, I want them to feel as if they've seen all of it before. They will feel more comfortable and be able to start using the software quicker. Software should facilitate a person's workflow, not act as a hindrance to it.

Programmers should bear in mind that they are writing tools for others to use, and insomuch as they can, try to understand the workflow of the target industry. I know more now about the health-care industry than I ever thought I would just from being a software developer. Get to know the type of person who will be using your application, and walk a mile in their shoes before you release your software.

  • 0

Apr 01 2011 02:56 PM
Agile development practices, frequent "beta" releases, and prototyping can all help this, as well. Ultimately, though, if the user is having problems with the software, there is a bug. It may be a usability bug, but it's still a bug.
    • 0
The problem with the nursing home records software was that the release was the beta. In addition to poor testing for logic errors, they never thought about usability from a nursing perspective. So when they decided to change something to make it better, it would sometimes confuse the nurses, resulting in endless support calls to my desk the day after the release. To sum it up, it was really just bad business practice.
    • 0
Great post, Greg! I agree with you in every thing.
    • 0
Same here. Agree with all that you said. Sometimes, as programmers, we forget people don't think the same way that we do, not because they are stupid, but just because they are different people, most likely with different jobs. And I know this is a problem with me, I tend to care about the cool thing I can do (e.g. using the latest technology or adding this cool feature) that I completely forget the user doesn't need all that fancy stuffs or barely use it.

What I love are programmers who tell me, as a tester, that I can't do a certain thing, like while going through a process, I can't hit a back button, because that will create a lot of problems.
    • 0
I would rather give something out free than face a angry customer who paid and didn't get. Add and verify the database listing as paid and then do the credit card transaction.
    • 0
Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download