other cognitive psychologists in using “intuition” in its folk meaning of everyday thinking. This meaning is elaborated in the description of System 1, and is mainly used in contradistinction to analytical thinking or to reasoning. The title of this article should thus be understood as an inquiry into the nature of the gap between the everyday “natural” meaning of objects and categories vs. their formal meaning in OOD. It should further be noted that intuition may have different meanings in different contexts. For example, our use of the term is quite different from the way a mathematician might use it when he or she says: “I had the intuitive idea of the proof long before I was able to complete the formal proof.”

 

INTUITIVE THINKING IN OOD

OOD is a complex domain, requiring formal training and effortful thinking, which is just the kind of process System 2 would be expected to appropriate. However, our research indicates that here too the auto-

Client

matic, quick, and effortless

Name

operation of System 1 may hijack software developers’ Login attention and lead them to ^Register decisions that are not adequate and may even clash with their own knowledge.

We discuss several examples of this phenomenon exhibited by experienced software developers in industry while practicing design activities, and explain them in light of the dual-process theory. We invoke this theory in the domain of OOD in an attempt to understand the relatively elementary mistakes we observed in the responses of intelligent capable professionals, even in cases when they have the necessary knowledge to avoid such mistakes.

Our observations took place within advanced UML workshops [ 8] conducted in the industry. During these workshops the participants were asked on several occasions to analyze simple design tasks. The participants worked on these tasks either individually or in small groups and their solutions were subsequently discussed within the whole group. Our data includes the written solutions of the participants in the workshops, documentations of their group discussions as observed and documented by the researchers, and transcripts of class discussions. The research population included 41 software developers with experience of 2– 12 years in OO development. Because our objective was to describe a complex situation in its natural settings and its full complexity, we have used the qualitative research paradigm [ 12], which focuses

A design of authorization system.

on case studies for obtaining specific insights rather than on large populations, simplified experiments, and statistical methods for discovering universal laws. (This is analogous to the methods used by anthropologists studying unfamiliar cultures.) During the research we documented, videotaped, and analyzed many relevant incidents and processes. The data analysis included coding the data obtained, and characterizing and classifying it to emerging categories. The full research findings and evidence will be described elsewhere. Here, we provide a selection of examples to demonstrate our findings.

Confusing the direction of inheritance. A design task
concerning a hotel reservation system was presented
for a discussion to a group of experienced engineers
participating in a UML workshop. The instructor
suggested using three classes (email, fax, and phone),
to represent the three corresponding modes of enter-
ing reservations. The possibility then arose of using
inheritance relations
between concrete classes
Server
to exploit shared func-
tionality and features,
ValidateUser such as checking the
^{InsertNewUser} availability of a room.
For example, the class
fax could inherit from the

class email, since a fax object requires more handling (such as scanning and digitizing), hence has more functionality, than an email object.

 

Instructor: Under the restriction that for now we only use these three classes, can any of these classes inherit from another class? Can we use the fact that they have many things in common?

[The participants hesitate]…

Instructor: For example, fax is like email, only with a few more tests.

Dan: Email inherits from fax, because email is the same as fax, only with fewer tests.

Instructor: So, email has less functionality than…

Dan [hastily]: Oh, right, it should be the other way around.

 

In view of this and similar observations, we presented a group of 10 software developers with a similar question in order to check this phenomenon more directly. The answers were divided 5: 5 between the two possible directions of inheritance. Significantly, as in the bat-and-ball and in Dan’s case, the participants who chose the wrong direction required only a small nudge (with no informational or explanatory content) to quickly change their mind.

Analysis: All the participants in the research have