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-
matic, quick, and effortless
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
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
between concrete classes
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
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