ProSysPlus | Hank's Job

What's My Job?

When I was a psychologist and my kids were 7 and 4, they cornered me in the kitchen one Saturday morning, quite obviously on a mission. The question, which my son (7) had (as usual <s>) gotten my daughter to ask was "Dad -- what do psychologists do?" You see, they knew what salespeople do, and firemen, and teachers. But psychologists? That's a tough question, but parental obligation (how could I possibly not answer them?) spurred the creativity required by the moment: "I help make people happy." They smiled, and thought that was pretty nice.

Now I develop software. What do I do now?

Sure, it means that I create forms, and databases, and reports, and tie them together. That's the process. But that's not my job.

My job is to provide a tool for someone else to use.

If they can't use the tool I've made, I've failed. Now, it may be the case that no one could have succeeded. It is still the case that I've failed.

Midpoint

When my son finished Kindergarten he and 3 of his friends (promptly labeled "The Gang of Four" in reference to historical events in China at the time) were among 15 children specially chosen for Midpoint. Academically qualified (he was in the gifted program), he wasn't ready to sit and focus for an entire day. Midpoint in his school was taught by a very special teacher, Sybil Spaulding, a veteran Special Education teacher with the patience of Job and the wit of the Irish. She needed both <g> for her class of 15.

One day I came to visit the class, and Sybil laughed as she told me about how my son, BJ, leaping head first into the tall classroom wastebasket when he found out he had gotten all his math problems correct (he went on to become a math major at RIT in Rochester, although he since switched to IT). I was pleased with her attitude, and told her so. She replied "if I can't con a 6-year old into doing what I want, there's something wrong with me." The student couldn't be the problem in her classroom, and the results showed.

The Point

The point of telling you about Midpoint, other than the pleasure of reliving the experience as I wrote it, is to point out that the user can never be wrong. My job is to produce a useful tool, and if the user can't make use of it, I have failed. Which raises the issue of why I've failed.

Only Experiments

Chairman Mao said (even the morally challenged can have good thoughts) "there are no failures in life, only experiments from which we learn to do differently." In that sense, then, I never fail. I do have many opportunities for learning. <s> Here are a few of the things I have learned:

Users don't do the task the way I would; because they are expert in doing the task and I am not.
Users don't want to know what I know in order to use the tool I am providing them; they want the tool to help them do their job, and don't want to learn my job.
Users cannot describe what they do: they are not perfectly mindful nor perfectly able to eff the ineffable, any more than I. Therefore I must observe what they actually do, and how they do it, in order to create their tool.
However, the user is the expert on what s/he does. Business Process Reengineering as practiced is generally a crock. If I want to find out what needs to be fixed in an organization, I ask the people who really do the work, in a setting in which they feel free to tell me the truth. Mostly, they are grateful for the opportunity to be heard. Of course, if they were heard by management, BPR wouldn't be needed. Listening to people and implementing their knowledge in the form of new practices assisted by software automation -- if that's what is meant by BPR, I'm all for it.
Even when I listen, I can hear inaccurately. What I consider basic, such as the esthetics of visual design, are culturally dependent; and the user comes from a vocational culture different than mine. Experiments will be necessary in order to determine what works for the user; I need to learn the user's culture. Thus the need for iterative development, which in turn demands a RAD development environment customizable to the task.
And even when the user communicates specifically, the user might not know to articulate aspects of the business process which are essential. I must bring my knowledge of business processes to the task. I have learned to beware the user saying "just…" because if the process were that simple, software wouldn't be needed. The user might want to save money by making the software so simple it ends up unable to do the job. If it can't do the job, I've failed. So, I've learned to use "complicating examples," typically introduced in the hypothetical: "could there be a situation where…" *

Lots of Experiments

The programming tools I use, then, had better allow for lots of experimentation. This means tools like Visual FoxPro, combined with Rapid Application Development add-ons, so the turnaround time between failures, er, experiments, is short. But tools are another topic…

* I made the same point, in expanded form, in "Business Rules: The (Visual) Basics," Visual Basic Developer (Pinnacle Press), November, 1999