Contrasts In Style

by Donald Ferrugia (c)
First published in Computerworld, Oct 1988
Reprinted by permission of the author

This has been difficult to substantiate scientifically, however, since most personality tests show computer people to be similar to the general population.

An informal survey I've been taking shows a big difference between computer people and others in one area that directly affects work habits, and this difference helps to explain a lot of the friction that occurs between computer people and users. When faced with a task, there are essentially two ways it can be approached: rule-based and choice-based.

Someone who is rule-based believes that there is a right way to accomplish any task and, when given a task to do, wants to be told the exact procedure to follow in order to complete it. When the same task must be done again, he will happily follow the same procedure over and over again. He gets satisfaction from completing the procedure and becomes anxious when the procedure doesn't work or must be changed.

Someone who is choice-based, on the other hand, doesn't like to be told how to accomplish a task and hates to do anything the same way twice. If given a set procedure to follow, he would rather ignore it or "improve" it with his own modifications. If the task is one that must be done repeatedly, he will become bored or will continually try new ways of completing it.

My experience has been that the general population, including users and higher management, is about 70% rule-based and 30% choice-based. I have found computer people, including programmers, analysts and their direct managers, to be more than 80% choice-based. Operations people seem almost 100% rule-based.

How does this explain the friction between computer people and users? Well, let's consider the main complaints of users about computer people: They're always late and they're constantly changing things.

Computer people are often late in delivering products, not because they are bad estimators but because they keep adding complexities to the product. It turns out that one thing won't work as well as they thought, another thing needs a total revamping and some aspect of a third thing pops up and needs attention. Even when doing minor revisions, programmers often make unrequested or cosmetic changes "because we were working on that area of the code already."

All this revision arises from the choice-based person's need to tinker. The longer choice-based people work on a project, the more "improvements" are going to be considered essential.

What are computer people's complaints about users? They don't know what they want and they sign off on proposals only to disavow them later. Even asking a rule-based person what he wants can put him in a state of panic; the idea of being able to choose feels like falling from a plane with no parachute.

Rule-based people want things to work the "right way," which usually means exactly what they are doing now. If you hand them a proposal, chances are they'll sign it because it's a concrete procedure that makes them comfortable. If they later see a system that works better than theirs, then that becomes the right way, and that's what they'll want. If you deliver a system and it isn't as easy as their current one (and "easy" here doesn't mean "less work," it means "fewer choices to make"), they complain that it's not what they wanted.

What are operations' complaints? They don't have all the detail they need and the exact procedures to run the jobs, and programmers don't follow all their rules. This is a basic conflict of choice-based vs. rule-based people.

What can be done to overcome these problems? First, discipline on the systems side to "build it first, fix it later," to keep new systems as much like the old ones as possible and not to introduce change for the sake of change. Prototypes are an excellent way to give users a concrete understanding of what they're buying.

Finally, those computer people who are rule-based can be used very effectively as user and operations liaisons. Users who are choice-based are not as effective as liaisons because they tend to raise the level of tinkering, not reduce it.