Fertile Zones of Cultural Encounter in Computer Science Education

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/240519490
Fertile Zones of Cultural Encounter in Computer Science Education
Article in Journal of the Learning Sciences · February 2008

DOI: 10.1080/10508400701793166
CITATIONS READS
27 68
2 authors:
Yifat Ben-David Kolikant Mordechai Ben-Ari

Hebrew University of Jerusalem Weizmann Institute of Science
70 PUBLICATIONS 1,614 CITATIONS 184 PUBLICATIONS 5,229 CITATIONS
SEE PROFILE SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Computer-science education as a cultural encounter View project
Non-determinism in CS View project
All content following this page was uploaded by Yifat Ben-David Kolikant on 11 March 2015.
The user has requested enhancement of the downloaded file.

This article was downloaded by:[Hebrew University of Jerusalem]
On: 6 May 2008
Access Details: [subscription number 791939160]
Publisher: Routledge
Informa Ltd Registered in England and Wales Registered Number: 1072954
Registered office: Mortimer House, 37-41 Mortimer Street, London W1T 3JH, UK
Journal of the Learning Sciences

Publication details, including instructions for authors and subscription information:
http://www.informaworld.com/smpp/title~content=t775653672
Fertile Zones of Cultural Encounter in Computer
Science Education
Yifat Ben-David Kolikant a; Mordechai Ben-Ari b
a
School of Education, Hebrew University of Jerusalem, Israel
b
Department of Science Teaching, Weizmann Institute of Science, Rehovot, Israel
Online Publication Date: 01 January 2008

To cite this Article: Kolikant, Yifat Ben-David and Ben-Ari, Mordechai (2008) 'Fertile
Zones of Cultural Encounter in Computer Science Education', Journal of the
Learning Sciences, 17:1, 1 — 32
To link to this article: DOI: 10.1080/10508400701793166
URL: http://dx.doi.org/10.1080/10508400701793166
PLEASE SCROLL DOWN FOR ARTICLE
Full terms and conditions of use: http://www.informaworld.com/terms-and-conditions-of-access.pdf

This article maybe used for research, teaching and private study purposes. Any substantial or systematic reproduction,
re-distribution, re-selling, loan or sub-licensing, systematic supply or distribution in any form to anyone is expressly
forbidden.
The publisher does not give any warranty express or implied or make any representation that the contents will be
complete or accurate or up to date. The accuracy of any instructions, formulae and drug doses should be
independently verified with primary sources. The publisher shall not be liable for any loss, actions, claims, proceedings,
demand or costs or damages whatsoever or howsoever caused arising directly or indirectly in connection with or
arising out of the use of this material.
THE JOURNAL OF THE LEARNING SCIENCES, 17: 1–32, 2008
Copyright © Taylor & Francis Group, LLC
ISSN: 1050-8406 print / 1532-7809 online
Downloaded By: [Hebrew University of Jerusalem] At: 07:55 6 May 2008
DOI: 10.1080/10508400701793166
Fertile Zones of Cultural Encounter

in Computer Science Education
Yifat Ben-David Kolikant
School of Education
Hebrew University of Jerusalem, Israel
Mordechai Ben-Ari
Department of Science Teaching
Weizmann Institute of Science, Rehovot, Israel
We explain certain learning difficulties in computer science education as resulting

from a clash between the students’ culture as computer users and the professional
computing culture. We propose the concept of fertile zones of cultural encounter as a
way of overcoming these learning difficulties. This pedagogical approach aims to
bridge the gap between cultures by designing interventions that are appreciated by
members of both cultures, yet also guide the student to engage in the practices of the
professional culture. The learning difficulties are demonstrated by a detailed analysis
of episodes taken from an advanced high school computer science course in con-
currency. We show that fertile zones of cultural encounter can be successful in signif-
icantly improving learning of this subject.
INTRODUCTION
Computer science (CS) education differs from other fields of science education not
only in its relative youth, but also in the extreme instability of the curricula and
teaching methods (Roberts, 2004). There are tensions between academia and in-
dustry professionals on the design of curricula, and there is mutual disappointment
between students and their instructors (Booth, 2001). Specifically, instructors
We are indebted to Sarah Pollack for her insightful comments on this article. We would like to thank
the editor and the reviewers for their extensive comments that contributed materially to improving the
article.
Correspondence should be addressed to Yifat Ben-David Kolikant, School of Education, Hebrew
University of Jerusalem, Mount Scopus, Jerusalem, Israel 91905. E-mail: yifatbdk@mscc.huji.ac.il
2 BEN-ARI AND KOLIKANT
complain that the naïve conceptions and work habits that students bring to class do
not disappear in advanced courses (Edwards, 2004; McCracken et al., 2001) and
that students do not adopt the thinking habits of successful professionals (Gries,
2002). Students, on their part, are concerned with the lack of immediate applicabil-
ity of their studies (Booth, 2001). In this article we suggest portraying CS educa-
tion as an encounter between two computer-oriented cultures: that of the teachers,
which is based on the academic CS world; and that of the students, who are veteran
users of computers (or in the words of Nardi & Miller, 1991, local developers). We
demonstrate the strength of this metaphor in understanding and resolving teaching
and learning difficulties.
The work presented here is based on a research project that accompanied the de-
velopment of an advanced CS course for high school students on concurrent and
distributed computation. Our objectives were to discover learning difficulties in
order to improve instruction. We found that the computer-oriented cultural back-
ground of the students influenced their understanding of situations and their subse-
quent behavior to the extent of sometimes delegitimizing learning opportunities
offered by the instructional settings. Furthermore, the awareness of the culture
clash and its reciprocal relationship with cognitive difficulties guided us to define
the concept of fertile zones of cultural encounter (FZCEs) as a pedagogical model
to resolve the culture clash and to facilitate the development by the students of a
professional perspective on computing so that they could appreciate the practices
and values that characterize this perspective.
We begin with a literature survey on the two major metaphors for learning
(the metaphor of construction and the metaphor of participation) as well as the
two major theoretical frameworks on learning within which these metaphors
exist (the cognitive framework and the sociocultural framework, respectively)
(Sfard, 1998). We then describe the process that led us to use the metaphor of
participation in addition to the construction metaphor, and we show how the
concept of culture clash enabled us to analyze the reciprocal relationship be-
tween the cultural and cognitive aspects of students’ learning difficulties in the
course on concurrency. Then we define and exemplify the concept of FZCEs
that we propose as a pedagogical approach for overcoming the culture clash at
the base of these learning difficulties.1
1To forestall a possible misunderstanding, let us note that there has been a lot of research into the
use of computers in teaching and learning. However, the research described here relates to the study of
computer science itself and not to the influence of the computer on the classroom culture in general or
on the learning of other specific subjects. For example, Schofield (1995) discussed the social and cul-
tural environment in a computer science classroom, but she was interested in the relations between stu-
dents and teachers (and students and students) that resulted from different levels of computer literacy,
not in any social effects or culture clash relating to the subject matter itself.
FERTILE ZONES OF CULTURAL ENCOUNTER 3
SURVEY OF PREVIOUS WORK
Cognitive and Sociocultural Frameworks

The theoretical framework for learning of cognitive constructivism uses the meta-
phor of learning as construction of knowledge. The individual’s knowledge exists
as a large structure of knowledge pieces interrelated by links of various types and
strengths, and learning is a continuous process in which new situations are inter-
preted within the existing knowledge structure in order to construct new knowl-
edge. Students will naturally use pieces of knowledge that were productive in pre-
vious situations even though they may no longer be so; hence, misconceptions
arise. These misconceptions initiate processes of refinement and extension of
one’s knowledge on the basis of the productivity of knowledge pieces in new situa-
tions (Smith, diSessa & Roschelle, 1993/1994).
A second metaphor is learning as participation (Sfard, 1998). This was the cen-
tral concept in the work of Lave and Wenger (1991), who portrayed learning as a
process of entering a community of practice by legitimate peripheral participation
in the genuine practice of the target community. Communities of practice are
groups of people who share similar goals and interests and who pursue their goals
by employing common practices; becoming a full participant means becoming
skillful with the repertoire of the tools of the community (Wenger, 1998).
According to Wenger (1998), cultures consist of composite repertoires of
shared capabilities created by interacting, borrowing, imposing, and brokering
among their constituent communities of practice. Roth and Bowen (1995) defined
culture to include both the resources and the practices of a given field, which they
defined as follows:
We use the notion of material, social, and conceptual resource to denote the instru-
ments, facts, phenomena, and theories scientists draw on in their work. Practice is the
label for the act of constructing (or deconstructing) physical and conceptual entities,
the resources of the field. (p. 76)
One’s understanding of culture is rooted in this concept of shared practices and re-
sources. This is consistent with the plea of Gutiérrez and Rogoff (2003):
We argue against the common approach of assuming that regularities are static, and
that general traits of individuals are attributable categorically to ethnic group mem-
bership. We suggest that a culturalhistorical approach can be used to help move
beyond this assumption by focusing researchers’ and practitioners’ attention on vari-
ations in individuals’ and groups’ histories of engagement in cultural practices be-
cause the variations reside not as traits of individuals or collections of individuals, but
as proclivities of people with certain histories of engagement with specific cultural
activities. (p. 19)
The reciprocal relationship between conceptual knowledge and culture was em-
phasized by Brown, Collins, and Duguid (1989), who claimed that conceptual
knowledge should be viewed as tools that change one’s perspective on the world.
Therefore, the activity in which conceptual knowledge is developed and deployed
is not ancillary to learning, but rather it is an integral part of what is learned. Simi-
larly, Resnick (1989) asserted that becoming competent in any complex subject
domain is “as much a matter of acquiring the habits and dispositions of interpreta-
tion and sense making as of acquiring any particular set of skills, strategies, or
knowledge” (p. 58). Thus, becoming a CS professional requires more than merely
mastering programming languages and being familiar with theoretical issues such
as computational models; it also requires enculturation into the culture of the disci-
pline or, in Schoenfeld’s (1992) words, the development of a unique point of view,
that is, valuing the processes professionals carry out during their work and having
a predilection to apply them.
Culture Clash
The concept of culture clash is found in research done on the way cultural diversity
influences education, in particular, in multiethnic schools (Brown, 2004; Rose-
bery, Warren, & Conant, 1992; Warren, Ballenger, Ogonowski, Rosebery, &
Hudicourt-Barnes, 2001); however, this work is of little relevance to our research
because the three schools in which we carried out the research were quite homoge-
neous in terms of ethnicity, language, religion, and socioeconomic class. Our con-
cern is rather with a clash between the computer-related culture of the students and
that of the teachers and the curriculum.
Much more relevant is the work of Labaree (2003), who described culture clash
between experienced teachers who are doctoral candidates and educational re-
searchers. Teachers are veterans in the educational arena; however, their perspec-
tive on education is inherently different from that of researchers. Labaree claimed
that the shift from teaching to educational research requires that the teachers trans-
form their cultural orientation “from normative to analytical, from personal to in-
tellectual, from the particular to the universal, and from the experimental to the
theoretical” (p. 16). Tension can occur when students’ learning difficulties are en-
countered. The primary commitment of teachers is toward the students, and thus
they seek to intervene early, whereas researchers “seek to clarify and validate argu-
ments about the functions and dysfunctions, causes and consequences of educa-
tional practices” (p. 17) and thus may defer intervention. This can cause teachers to
suspect and resist (sometimes subconsciously) activities typical of educational re-
search.
Neumann, Pallas, and Peterson (1999) suggested that, to resolve these tensions,
the teachers’ perspective should be made explicit and should be respected; further-
more, the researchers’ perspective should be offered as an additional, but not nec-
essarily preferred, perspective. Labaree, in contrast, saw the researchers’ perspec-

tive as significantly different from that of the teachers; he sought to facilitate a
process of enculturation toward the researchers’ culture by having researchers em-
phasize those similarities—such as their dedication to education—that would fa-
cilitate the achievement of legitimacy from the teachers.
Two Cultures in Computing

During the past two decades computers have ceased to be professional tools and
have become central artifacts in many communities of practice. For the purposes of
this article, we distinguish between two computer-oriented cultures, which we call
the user culture and the professional culture. A user is defined by Turkle as some-
one who is “involved in the machine in a hands-on way, but is not interested in the
technology except as it enables an application” (Turkle, 1995, p. 32). The profes-
sional culture is represented, for example, by professional programmers. The two
cultures are not mutually exclusive and, in many cases, the borderline is not clear
cut (Goodell, Maulsby, Kuhn, & Traynor, 1999, Nardi, 1993).
To avoid misunderstanding, we emphasize at the outset that we do not intend to
divide people into cultural groups (cf. the quote from Gutiérrez & Rogoff, 2003,
above), nor do we claim that one culture is superior to the other; it is all a matter of
context and situation. Furthermore, people can behave differently in different con-
texts. A “user” of a software package may exhibit behavior and a depth of comput-
ing knowledge associated with a professional perspective; for example, a statisti-
cian or accountant may have an in-depth knowledge of the algorithms used in a
spreadsheet program. Conversely, a “professional” programmer or software engi-
neer may use a software package, such as an image editor, to prepare a presentation
in a manner consistent with the user perspective. In our case, we found that the stu-
dents brought a user perspective into a classroom situation for which it was not
suitable.
We now give four dimensions that we use to distinguish between the two cul-
tures:
1. The cultures are distinguished by their judgment as to what counts as a

problem to be solved and what is considered to be an acceptable solution.
For example, from the professional perspective, the unexpected behavior
of a program is indicative of an error in the program. In the context of soft-
ware development, a programmer would set a goal to analyze the error and
to design and implement a solution. From the user perspective, an unex-
pected behavior of the program might be tolerated, in particular, when it
does not prevent the achievement of the original goal for the interaction
with the computer. An episode reported by Turkle is typical. She described
a conversation with Tim, a 13-year-old boy, as she and Tim were playing
Simlife, Tim’s favorite computer game, which sets its users the task of cre-
ating a functioning ecosystem. The message “Your orgot is being eaten up”
flashed on the screen, and the following conversation ensued:
I ask Tim, “What’s an orgot?” He doesn’t know. “I just ignore that,” he says.
“You don’t need to know that kind of stuff to play” … “I think it is sort of like an
organism. I never read that, but just from playing, I would say that’s what it is.”
(Turkle, 1995, pp. 69–70)
When the message popped up, Tim ignored it, showing no interest in un-
derstanding what caused it to happen. When asked, he explained that it is
unimportant because he could still achieve his original goal of interacting
with the computer. In the context of a computer game, such behavior is pro-
ductive.
2. The second dimension concerns the approach to problem solving when us-
ing computers; for example, what is the reaction to unexpected output on the
screen? An interaction dominated by the perspective of the professional cul-
ture involves a multilayered approach to problem solving, moving back and
forth between different layers of abstraction: the interface, the computer pro-
gram, underlying software such as the operating system, and the machine
that is executing the program (Aho & Ullman, 1992; Hartmanis, 1995).
Within the user culture, interaction is primarily at a single layer, that of
the interface (Turkle, 1995). The underlying layers remain opaque and are
not used in problem solving. The term user-friendliness is indicative of this
type of interaction, because it implies that users can interact with a com-
puter through a graphical user interface without having to understand the
underlying algorithms or software.
3. The cultures also differ in their appreciation of development processes and
computing knowledge. The work habits and learning preferences that char-
acterize the user culture emphasize hands-on activities:
A motivational paradox arises in the “production bias” people bring to the task
of learning and using computing equipment. Their paramount goal is through-
put. This is a desirable state of affairs in that it gives users a focus for their activ-
ity with a system, and it increases their likelihood of receiving concrete rein-
forcement from their work. But on the other hand, it reduces their motivation to
spend any time just learning about the system, so that when situations appear
that could be more effectively handled by new procedures, they are likely to
stick with the procedures they already know, regardless of their efficacy.
(Carroll & Rosson, 1987, pp. 80–81)
Users appreciate a development process based upon exploring technologi-

cal artifacts; therefore, they tend to appreciate functional knowledge fo-
cused more on the question “How can I make it work?” and less on the
question “Why does it work the way it does?” (Turkle, 1995).
Within the professional culture, there is a greater appreciation of abstract
knowledge of data structures, algorithms, and computational models, as
well as of formal development activities, such as analysis, design, and doc-
umentation. The professional culture also values attributes such as effi-
ciency, robustness, and readability, all of which are based on the ability to
work on multiple layers (Booth, 2001; Hoare, 1989; Knuth, 1974, 1985).
4. An additional dimension of the variation between the cultures relates to
computer technology, in particular, to enthusiasm toward new technology.
From the professional perspective, one inevitably faces external con-
straints on the choice of computer technology, for example, compatibility
with legacy systems. In contrast, users (especially those who program for
their own purposes as opposed to those who use software packages in their
work) are free to seek out innovations.
The CS Classroom as an Arena for Culture Clash

CS curricula—as opposed to programs in computer literacy or applications—are
invariably designed by CS academics to emphasize stable scientific principles
such as algorithms and programming language concepts, as well as the best soft-
ware engineering practices such as design and documentation (College Board AP,
2006; Gal-Ezer, Beeri, Harel, & Yehudai, 1995). The professional perspective is
particularly apparent in the course we developed on concurrent and distributed
computation. During the execution of a concurrent program composed of several
processes, instructions of the processes interleave arbitrarily so that two execu-
tions of the same program on the same input can bring about different outputs.
Therefore, running a program and examining the output provides almost no knowl-
edge about the correctness of a program, thus weakening the effectiveness of ap-
proaches to problem solving that are too distinct from the formal activities of the
professional perspective. It is precisely this property of nondeterminism that
makes concurrency such an attractive CS subject because young students can be
exposed to the necessity of using a formal approach within the small-scale activi-
ties of a computer lab.
Students, naturally, bring their own experience with computers to school. This
experience includes both previous CS courses in school, as well as out-of-school
activities with computers. We believe that their user perspective can lead to
delegitimization of formal CS education, and that this is implicit in the ongoing
disappointment reflected in the literature of CS education that focuses on students’
behavior. For example, Gries complained that students fail to grasp the “thought
habits” of experts (Gries, 2002, p. 6). Instead, as claimed by Edwards (2004), “stu-
dents rely on trial and error for too long,” and their insufficient work habits strike
roots “despite [teachers’] best efforts” (p. 26). From his point of view, students
miss learning opportunities because they try to avoid analyzing the problems that
are encountered and instead prefer to “switch around things”; note, however, that
the students’ goals and activities resemble the user perspective that prioritizes the
question how to make it work over the question why it didn’t work:
My code looks “correct” to me. If it produces the wrong answer, that does not make
sense, so there must be something hidden that I don’t understand about my code. I
will try switching around a few things to see if I can make the problem go away. (Ed-
wards, 2004, p. 26)
The wealth of findings regarding students’ alleged shallow behavior (e.g.,

McCracken et al., 2001) invite investigation as to why so many students behave
this way. Currently in CS education research, especially that on learning difficul-
ties, the dominant perspective on learning and knowledge is cognitive. A discus-
sion of constructivism as a theoretical framework for CS education can be found in
Ben-Ari (2001). In two recent reviews of the state of the art in research in CS edu-
cation, the dominant theoretical viewpoint on learning was cognitive (Robins,
Rountree, & Rountree, 2003; Simon, Fincher, & Lister, 2006 ). Many studies have
concerned the knowledge of expert and novice programmers, with an emphasis on
novice difficulties (Soloway & Spohrer, 1989) and on determining what knowl-
edge brings about what strategies and what abilities emerge (Davis, 1993; Rist,
1995). Recent studies have focused on issues relating to the object-oriented pro-
gramming paradigm. For example, Wiedenbeck, Ramalingam, Sarasamma and
Corritore (1999) examined the ability to comprehend a program among novices
who studied the object-oriented paradigm as compared with novices who studied
the procedural paradigm; they ascribed the differences between the groups to the
difficulties of forming mental representations of the function and the control flow
of the object-oriented program. Recently, however, interest has been growing into
the potential of the sociocultural perspective on learning to advance research in CS
education (Ben-Ari, 2001; Clark & Boyle, 1999; Holmboe, 2004, 2005; Holmboe,
McIver, & George, 2001; Hundhausen, 2002). This theoretical framework encour-
ages a shift in the foci of CS education research projects to the processes students
undergo as they study in the hope that this will provide additional explanations of
student behavior.
OUR PREVIOUS WORK
Research Background
From 1998 to 2003 we developed a course on concurrent and distributed computa-
tion for high school students. A main topic of this course is that of synchronization;
students are introduced to fundamental synchronization problems in various com-

putational models and solve these problems using different programming mecha-
nisms to achieve synchronization. The course is one of the theory electives offered
as the last of a five-unit curriculum in CS (one unit is 90 hr of frontal lectures and
lab sessions) spread out over the 3 years of high school. Because only students with
a high level of achievement will elect to take such an extensive set of science
courses, the students are invariably of high cognitive ability. Furthermore, because
they have succeeded in studying at least 270 hr to get to this point (learning at least
two programming paradigms and passing matriculation exams in these units), one
can assume that they are comfortable with basic concepts of CS like program, cor-
rectness, and so on, and that they are fully capable of writing and debugging small
programs and learning new programming languages and techniques.
Research Methods
The methodology we used can be described as follows: (a) We used a diversified
set of tools (tests, videotapes of lab sessions, observations, and interviews) to ob-
tain various perspectives on the knowledge structures of the students; (b) the inves-
tigation proceeded at two levels: a macrolevel view of an entire class in order to ob-
tain a general perspective, and a microlevel view of individuals in order to achieve
an in-depth investigation of phenomena; (c) additional data collection points and
reanalysis of data was carried out as needed; (d) data were collected almost exclu-
sively from the integral in-class activities to avoid affecting the learning process.
The research was carried out during 4 consecutive years that the course was
given. We aimed to achieve an overview of the learning of this subject, of the na-
ture of the instructional process, and of the evolution of students’ knowledge. A
preliminary research program was conducted for 2 years, each year on one class of
12th-grade students. This phase of the research was also used to improve the
course, to shape the research methodology, and to fine-tune the methodological
tools. The methodology, the findings of this phase, and the implications for the
course are presented in Ben-Ari and Ben-David Kolikant (1999) and Ben-David
Kolikant, Ben-Ari, and Pollack (2000).
The final 2 years were devoted to the main phase of the research and empha-
sized an in-depth investigation of the evolution of students’ knowledge as they
studied the topic of synchronization using semaphores. The research was con-
ducted in six classes from three schools and involved about 150 students. The
schools that were chosen for the main phase of the research had a history of 10
years of successful participation in innovative teaching and development projects
with our group at the Weizmann Institute of Science. All of the teachers had expe-
rience teaching new courses and volunteered to teach this one; they all had gradu-
ate degrees and had taken a selective course for training leading teachers of CS. All
students had frequent access to computers.
The research comprised two phases. First, the existing knowledge of the stu-
dents at the beginning of the course, in particular their preconceptions on synchro-
nization, was explored using the responses of all of the students to three synchroni-
zation problems posed in questionnaires (Ben-David Kolikant, 2001).
The next step was to explore the knowledge that the students gained during the
2 months they studied synchronization using a programming construct called
semaphores. To this end, the students were given two tests, Test A and Test B. Ad-
ditionally, a few students were interviewed in order to clarify the knowledge un-
derlying their performance during the tests. In order to investigate the process of
knowledge evolution, one class of 19 students was observed for the entire time
they studied this topic, and several students of this class were videotaped during a
lab problem-solving session and were also interviewed. In order to validate the
findings, observations and videotaped lab sessions were repeated during the fol-
lowing year in the same school with the same teacher (this time with 39 students).
During the vacation period between the 2 years and throughout the second year, the
teacher was intensively guided to anchor her teaching within the concept of cul-
tural encounter.
Summary of the Results of the Research

In this section we summarize the results of Ben-David Kolikant (2004a, 2004b),
where the evolution of students’ knowledge is reported.
One of the questions on Test A presented two programs for the fundamental
synchronization problem called the critical section problem and asked the students
to analyze their correctness. The programs were designed so that a correct answer
required understanding the semaphore concept and mastery of its use. In all, 43%
of 129 students who responded to this question failed to solve this question; an
analysis of their responses revealed that most of them made incorrect assumptions
about the definition of semaphore operations, in particular, on the change in the
program state resulting from executing the semaphore operations. Each student re-
ceived detailed feedback, including not only an explanation of his or her mistake
but also a reminder of the correct definitions and their effect on the program state.
The semaphore operations were also reviewed in class.
Next, about 3 weeks after Test A, Test B was given, in which the students were
again given the same scenario of program execution that many had failed to under-
stand in Test A. Surprisingly, despite the intensive pedagogical intervention after
Test A, 35% (of 99 students who took the exam) again used incorrect definitions of
semaphores. Obviously, the students’ initial understanding of semaphores in-
cluded misconceptions. However, we had expected that the repeated failures
would enable students to recognize that their current knowledge of semaphores
was not productive, and this should have driven them to extend and refine their
knowledge based upon material that was accessible in the intensive feedback, the
book, and the laboratory environment (Smith et al., 1993/1994). Specifically, we

expected that students would utilize their 2 years of experience debugging pro-
grams to explore the dynamics of the execution of their incorrect programs in order
to answer the question “What is wrong in my program?” This was based upon the
assumption that the activity would (a) cause them to realize that they held an incor-
rect definition of semaphores and (b) provide them an opportunity to explore these
definitions. Observations throughout the course revealed that many students did
not possess the propensity to act in this manner, although the environment sup-
ported this activity. We were left with following question: “Why did the intensive
feedback not prove productive for the students?”
Ben-David Kolikant (2004b) was our first attempt to analyze learning difficul-
ties from a cultural perspective. We analyzed the work of two pairs of students in a
problem-solving session in the laboratory. The students, working in pairs, were
asked to solve the grade assignment: They were given a skeleton of a three-process
program that was designed to calculate the final grade of a student given three
grades in each of two semesters (see Figure 1). The students were asked to syn-
chronize between the three processes of the program.
The students were videotaped, and the videotapes were transcribed. The analy-
sis focused on the work processes of the students. The students’ phrases and ac-
tions were classified according to stages of problem solving: analysis, design (in-
cluding implementation), and verification. (Two additional types of actions—
reading the assignment and experimenting with the environment—were omitted in
the analysis because they were not relevant for our research questions.) Each ac-
tion was categorized as dominated either by a user perspective or by a professional
perspective. The former are actions that are based entirely on the interface without
any reference to the underlying layers of the programming code and the computa-
tional model (e.g., designing a solution based upon the manipulation of objects
FIGURE 1 Required program scheme and synchronization. The arrows represent the re-
quirement that process Average should not calculate the average before processes First and Sec-
ond have calculated max. The dotted line represents the requirement that the input of processes
First and Second from the shared keyboard not interleave.
such as semaphores without identifying the requirements of synchronization). Ac-

tions ascribed to the professional perspective refer to three layers: the interface, the
program code, and the computational model (e.g., designing a solution that takes
into account the influence of the semaphore operations on the internal states of the
program).
One pair, Y and M, initially approached the problem from a user perspective.
When they encountered an unexpected output due to incomplete synchroniza-
tion, they reexecuted the program, and when the output refused to disappear they
asked for help (from the first author; T). The transcript shows no attempt to in-
vestigate the program code; rather, their interpretation of the situation was solely
from the perspective of users who misunderstood the instructions provided by
the interface:
Y: [pointing to two lines of unexpected output] The question is what do they

[the processes] request? What do they [the processes] ask for?
T: Can you explain the meaning of these two lines [of output]?
Y: They tell me to enter the data of the second semester and then to enter the
data of the first semester.
T: How did you get to this conclusion?
Y: Because it [the computer] asked me to. [Reads the line from the screen:]
Type the grades of the second semester.
T: What is ‘it requests,’ who is it? I wrote this program.
Y: I don’t know either you or the computer. It is none of my concern who
wrote it [this program]. I’m coming to the computer now and that’s what it
tells me to do. Right?
We believe that the students’ difficulty resulted from their perspective: Rather
than experiencing the situation as programmers encountering a problem to be ana-
lyzed and solved, the students thought as users interacting with a nonfriendly com-
puter artifact. In fact, in the continuing conversation when the students were asked
to explain why the execution of the code had brought about the unexpected output,
they began utilizing the two underlying layers, the program code and the computa-
tional model, to answer the question, and this enabled them to identify the prob-
lem. Y gradually engaged in activities characteristic of the professional perspec-
tive, and this enabled her and M to produce a correct solution. M, however,
retained the user perspective, saying “I’ll run it and you’ll see it works.” A similar
phenomenon was observed in another pair of students as described in Ben-David
Kolikant (2004b).
The research described in the current article shows that the results of Ben-David
Kolikant (2004b) are not an isolated difficulty of two pairs of students trying to
solve a single exercise; instead, cultural influences on learning CS are deep and
pervasive.
ATTRIBUTING LEARNING DIFFICULTIES

TO CULTURE CLASH
The CS culture clash is presented by describing three types of learning difficulties

that we encountered in our course on concurrent computation: (a) the definition of
the correctness of a program and of a “working” program, (b) the appropriateness
of assignments, and (c) the suitability of the programming environment used for
exercises. The first is presented in great detail in order to demonstrate how the exis-
tence of culture clash arises from the evidence; the other two are presented briefly
in order to demonstrate that the phenomenon is pervasive and not incidental. In
each case, we describe the following:
• Expectation: the expected outcome in terms of the professional perspective;

• Learning difficulties: the learning difficulties that were uncovered;
• Possible explanations: the various ways that the difficulties can be explained
without invoking culture clash;
• Culture clash: the contribution that the perspective of culture clash can make
to elucidate the source of the learning difficulties.
The Definition of Correctness

The following problem was presented to 138 CS students:
A system consists of three entities E1, E2, and E3 that are to be executed concur-
rently. The sequence of operations of the entities includes the operations Op1, Op2
and Op3, respectively. Add a synchronization mechanism to the program in order to
ensure that operation Op1 will be executed before Op2 and Op3. No other constraints
are to be imposed on the sequences of operations executed by the entities; that is, a
solution is correct only if it allows all scenarios that satisfy the synchronization re-
quirement. Explain your decision.
This problem was the third question in Test A described above. The students
were given a set of five potential solutions and were asked to evaluate the correct-
ness of each one. Three of these are shown in Figure 2.
The correct solution is Solution A. Solutions B and C are incorrect because they
impose unnecessary constraints. Solution B ensures that Op1 executes before Op2
and Op3, but it also unnecessarily constrains the execution to those scenarios in
which Op2 executes before Op3. Solution C constrains the execution so that all of
the operations of entity E1 (not just the operation Op1) are executed before all of
the operations of the other two entities. This is analogous to a system that con-
strains one’s work so that an entire Web page has to be downloaded without allow-
ing the concurrent execution of the word processor.
FIGURE 2 Solutions offered in Test A. E = entity; Op = operation.
Expectation. The expected outcome—as explicitly required in the statement

of the problem—was to choose the only solution that fulfils the synchronization
requirement without unduly constraining the possible executions of the program.
This is not an arbitrary demand but an essential feature of the model that is de-
signed as an abstract framework for studying concurrent systems. Professional be-
havior requires that problems be solved within constraints that always exist. In the-
oretical academic work, the use of a shared model enables results to be compared;
in industrial work, there are always limitations caused by the hardware, existing
software, cost, and so on. Disagreements about constraints must be resolved before
problem solving commences.
Learning difficulties. The analysis of the students’ answers is presented in

Table 1. Following an initial classification of the answers as correct or incorrect,
we further subdivided the incorrect solutions into false positives (claiming the so-
lution is correct when it isn’t) and unjustified negatives (recognizing that the solu-
tion is incorrect but for the wrong reasons). We were particularly interested in the
false positive answers, because these students were willing to accept as correct so-
lutions with unnecessary constraints despite explicit instructions to the contrary. A
significant percentage of the students fell into this category: 37% (Solution B) and
41% (Solution C) of the 138 students.
Here are some quotes from the explanations given by the students:
Solution B is correct because in all interleavings Op2 and Op3 are performed after
Op1.… In fact, the operations are performed in a sequence: after Op1 is done by en-
tity E1, entity E2 performs Op2, which enables Op3 to be performed.
Solution C is correct because all interleavings enable us to fulfill the goal of execut-
ing Op2 and Op3 after Op1. It doesn’t matter where you put [the synchronization
command] as long as it is before Op2 and Op3 in each process.
TABLE 1
Students’ Decisions and Reasoning on Correctness (n = 138)
Response
Solution B Solution C
Decision and Reasoning n % n %
Claim (incorrectly) that the solution is correct 51 37 56 41

The explanation includes a recognition of the existence of the 36 26 28 20
unnecessary constraints, yet the student claims the solution
is correct because only good scenarios are possible.
The explanation includes the statement that solution is correct 0 0 13 9
because only good scenarios are possible; there is no
explicit recognition of the unnecessary constraints.
No explanation is provided. 15 11 15 11
Claim the solution is incorrect but the justification is wrong 12 9 21 15
Unexplained claim that a bad scenario can happen. 9 7 12 9
Incorrect assumption concerning the computational model. 0 0 3 2
Misunderstanding of the synchronization requirement. 1 1 5 4
Misunderstanding of the semaphore. 2 1 1 1
Correct decision and explanation 75 54 61 44
Total 138 100 138 100
Solution C is correct. Although there are some good scenarios that are not allowed
because Op3 is always [executed] after Op2, Op1 is always [executed] before Op2
and before Op3.
The teachers solved Test A in the classroom and discussed the incorrect an-
swers. As long as their mistakes were due to straightforward mistakes, students ac-
cepted the teachers’ explanations. However, the teachers’ explanations concerning
the false positives were greeted with a storm of protest. In response to the teacher’s
claim that Solution B is not correct because it does not satisfy all of the require-
ments, the following discussion took place:
S1: The solution is OK.

Teacher: What do you mean by OK? It does not fulfill all the requirements. What
is the definition of correctness?
S2: What difference does it make? You wanted Op1 to always be [executed]
first. That was what was important. Well? Here I have that Op1 executed
and only then Op2 and only then Op3.
S3: When someone executes the program he does not know what happens
inside [the computer]—all the interleavings. To him it is OK.
Teacher: Yet, when a programmer is asked to write a program to do A and B and

the program does not do B then it is not correct.
S2: With all due respect, this is just petty, capricious.
Possible explanations. Clearly, one can attribute some of the incorrect an-
swers (the unjustified negatives, 9% and 15% of the students) to difficulties in un-
derstanding the semaphore or the computational model. However, the large num-
ber of students who accepted Solutions B and C cannot be attributed to this reason.
Their careful use of the concepts and terminology of interleaving in their explana-
tions shows that these were well understood: “In fact, the operations are performed
in a sequence …”; “It doesn’t matter where you put [the synchronization com-
mand] …”; “Although there are some good scenarios that are not allowed …”
Another possibility is that the students did not understand the synchronization
requirements properly; this could be inferred from S2, who said, “You wanted Op1
to always be [executed] first. That was what was important. Well? Here I have that
Op1 executed and only then Op2 and only then Op3.” But S2 did notice the (sec-
ond) requirement for avoiding unnecessary constraints, only he believed that it was
not important, as reflected in the phrase “that was what was important.” Similarly,
the rest of the conversation with S2 and S3 showed that they were aware of the re-
quirement: S2 said, “What difference does it make?” and S3 explained why the re-
quirement was not important or even reasonable. As shown in Table 1, 26% of the
students explicitly acknowledged that they were aware of the unnecessary con-
straints but nevertheless decided that Solution B was correct.
It is also possible that some students simply ignored the requirement to work
within the constraint, but that would not explain the passionate nature of the de-
bate. Much of school learning must seem “petty, capricious” to students, so why
should they care so much about one more burdensome and arbitrary requirement?
Culture clash. We were led to conclude that many students were fully aware
of the requirement to avoid unnecessary constraints and understood the require-
ment, but they rejected its legitimacy. They claimed that avoiding unnecessary
constraints was certainly not crucial or, worse, that the requirement came from pet-
tiness on the part of the teachers. We further concluded that the delegitimization
arose from these students’ background within the practices of the user culture with
its different standards of correctness; otherwise, why would they bother to engage
the teacher in defending their point of view? Furthermore, S3’s argument about
what constitutes correctness originated in the user perspective, as can be inferred
from his insistence on defining correctness at the interface level: “When someone
executes the program he does not know what happens inside [the computer]—all
the interleavings. To him it is OK.”
The teacher, in turn, did not legitimize the students’ definition of correctness. It
is possible that this was simply a rote insistence on following the definitions of the
textbook, but this teacher fully understood the background of the course. We prefer
to see her as an authentic representative of the professional culture defending their
practices, and this led to an inevitable culture clash with the students. S2’s charac-
terization of the teacher’s advocacy of the professional perspective (“… when a
programmer is asked to write a program …”) as pettiness emphasizes the differ-
ence between the perspectives.
Working Programs
The students’ definition of correctness was generally consistent with the use of
software in the user culture (cf. the quote from S3 above): As long as the interface
to the program reacts as expected, the program “works.” The conversation below
demonstrates this definition. It occurred right after Student F submitted a lab report
including a printout of the program he developed to solve an assignment (the
grades assignment shown in Figure 1). His solution did not fulfill one synchroniza-
tion requirement, and that caused the program to print the wrong result as well as
other strange messages (the same messages that Y and M dealt with as described
above).
Expectation. The difficulties of testing software are well known, and every
one of us has experienced “bugs” that cause our computers to fail to perform as ex-
pected. Once a test has shown the presence of a bug in the context of testing, pro-
fessional behavior requires that it be acknowledged and fixed, although external
constraints like version release dates or the cost of making the fix may lead to an
acceptance of bug’s presence. It would be totally inconsistent with professional be-
havior to ignore the existence of a bug.
Learning difficulties. Here is the exchange between F and the teacher:
1. F: That’s it. [Hands in the printout and the lab report.]

2. Teacher: [Looks at the printout and then back at the student.] Did you check
it?
3. F: Yes.
4. Teacher: How?
5. F: I executed it.
6. Teacher: And [what happened]?
7. F: It works. It prints some garbage at the top of the screen but that
isn’t important.
8. Teacher: [Goes to student’s computer.] Show me.
9. F: [Executes the program, enters the input and points to the screen.]
Here, it works.
10. Teacher: Is it the output you were expecting?
11. F: I don’t know.
12. Teacher: That is not professional; plan your input and then check if the
output meets your expectations.
13. F: [Calculates with pencil and paper, executes and enters input and
points to the screen] Ah! No, it’s not [the expected output].
14. Teacher: OK, correct it, please.
There are two problems with F’s actions: (a) F did not attribute any importance
to the appearance of the unexpected output, nor did he think it relevant to the cor-
rectness of his solution (Lines 7–9); (b) although he did check his program by exe-
cuting it, he did not verify the result with an expected result until asked to do so by
the teacher (Lines 10–13).
Possible explanations. Recall that these students had studied CS and pro-
gramming for more than 2 years, so the concepts of bugs and of testing a program
to find them were not alien to them. In fact, F acknowledged that he checked the
program (Lines 2–3), and he expressed no objections whatsoever to the teacher’s
questions. F recognized the unexpected behavior of the program (Line 7), but de-
spite the fact that the context was program testing, he classified this behavior as un-
important garbage. Why? It is hard to accept the possibility that F recognized that
the program’s behavior was problematical, tried and failed to fix the bug, and then
intentionally decided to “pass off” the program in the hope that the teacher would
not notice. After all, F, in the crucial Line 7, readily admitted that the program
printed garbage, and yet he was totally unmoved by its presence.
Another explanation is that F believed that it was sufficient to check a program
merely by observing its output without calculating the expected outcome; this fol-
lows from the fact that he used this technique in front of the teacher’s eyes in order
to prove to her that his program worked (Lines 9–11). The fact that the teacher’s
short intervention (Line 12)—an intervention that did not include guidance con-
cerning the content of the (synchronization) problem—led the student to use her
technique shows that F knew what the teacher was talking about. Rather, he did not
have the propensity to use this knowledge without the intervention. Why? Perhaps
F was biased by his certainty in the correctness of his solution that when he exe-
cuted the program he anticipated no problem, and therefore he was satisfied when
a reasonable output was displayed on the screen (Leventhal, Teaslley, & Schertler
Rohlman, 1994).
Culture clash. F announced that the program worked (Line 7) and at the
same time reported on unexpected behavior of the program, classifying it as unim-
portant. This concept of a working program that tolerates unexpected “garbage” is
consistent with a user perspective as to what counts as a problem. F felt none of the
discomfort that is characteristic of professional behavior in the presence of a bug in
the context of debugging; in fact, he was the one who used the word “garbage” of
his own accord. F’s behavior is consistent with Wenger’s claim that one’s sense of
cultural belonging determines what one classifies as important and as unimportant
in any situation (Wenger, 1998).
An insight into F’s cultural background is provided by the situation Turkle de-
scribed as she and Tim were playing Simlife (see above). F’s behavior is similar to
Tim’s in the sense that both were willing to accept the appearance of an unexpected
message because it was irrelevant to the achievement of their goals. Both F and
Tim exhibited behavior consistent with the user culture; however, what is innocu-
ous in the context of a child playing a game cannot be legitimate behavior in the
professional culture when testing a program.
Appropriateness of Assignments
Problems in academic CS are frequently couched within imaginative cover stories;
for example, one of the most famous such problems is the called the dining philos-
ophers problem (for details, see the Appendix). These problems have proved to be
effective in both academic theory and industrial practice. Familiarity with a rich
repertoire of such problems facilitates professional work on “real” problems, be-
cause the artificial problems abstract the crucial features of real problems. The din-
ing philosophers problem that talks about philosophers needing forks to eat spa-
ghetti is a cover story for real problems of resource allocation. In our course, it felt
natural to follow the practice of the professional culture and to use these artificial
problems.
Expectation. The dining philosophers problem was not the first artificial
problem that students encountered during the course. The textbook included prob-
lems on rabbits and on robots, and these were solved in the book and discussed by
the teachers. Therefore, we expected students to solve the dining philosophers
problem by adapting solutions to previous problems or by building directly on the
definition of semaphores. Either way would have been a legitimate process of
knowledge refinement.
Learning difficulties. Students did not like this activity and did not even in-
terpret the problem within the formal model, preferring instead to remain within
the domain of the cover story. Their solutions were built upon assumptions that
were unrealistic within the computational model.
Possible explanations. It is possible that the students had not mastered the
model of concurrency and synchronization that was taught in the course; if so, how
were they able approach other assignments, such as the grade assignment, as ex-
pected? Probably, some of them did not recognize the similarity between the din-
ing philosophers problem and the grade assignment; yet, they could have tried to
work the problem out from the scratch, refining their knowledge with assistance
from the teacher, the textbook, and the computer.
Another explanation is that they found it difficult to make a connection between
the model and the cover story. This explanation has much to recommend it, as the
students did not attempt to approach the problem as a synchronization problem us-
ing the tools they had previously studied: identifying the shared resources (the
forks) and the processes that compete for the resources (the philosophers), and
then constructing a solution using semaphores. Possibly the intrinsic difficulty of
the dining philosopher problem led the students to dislike the activity.
Culture clash. We believe that the students delegitimized the problem itself
because it did not directly relate to computer systems. For example, one student
initiated a conversation with the first author “for the sake of future students,”
claiming the following:
I don’t see the point in teaching these things, such as the computational model, re-
quirements, proof and all these things, all these problematic philosophers. What is
the point? When do you write something? A program? In other courses you write
[programs], you do things.
The entire tenor of the quote is culture laden; the main complaint is about the
relevance of the abstract knowledge that was taught to the study of CS. The rejec-
tion of theoretical knowledge, such as the concept of computational model, is evi-
dent by the comparison that the student makes to other courses where students
“write [programs]” and “do things.” From this perspective, it is possible that stu-
dents’ refusal to work on the problem was caused by their delegitimization of the
problem.
Culture Clash in Software Technology

Our course used a concurrency simulator, called CP, descended from the original
one described in Ben-Ari (1982). CP was developed more than two decades ago as
a character-based program running in a DOS environment such as the “Command
window” of a personal computer. The simulator supported a dialect of the Pascal
programming language that the students were already familiar with.
From our perspective, the only really important criterion for choosing software
for the laboratory was its pedagogical adequacy, in the sense that the software
should allow the student to run all of the examples and exercises from the textbook,
to control the execution of the programs, and to observe the weird results charac-
teristic of concurrent programs.
Expectation. We were aware that the students—used to modern software

tools with graphical user interfaces—would look upon the interface of CP as prim-
itive and the Pascal language as outdated, but we expected that their use would be
legitimized, as they were used solely for the purpose of studying the scientific prin-
ciples of concurrent programming. Furthermore, in none of the courses studied
previously to the course had the students used a graphical interface, and we as-
sumed that students were to some extent acculturated with the professional per-
spective of technology as merely a tool for solving problems, frequently under
constraints.
Learning difficulties. The CP concurrency simulator was not readily ac-

cepted by the students. They were disappointed that no modern language was be-
ing used, and they repeatedly attributed their failures to the “backward” technol-
ogy used instead of engaging in problem-solving activities.
Possible explanations. The CP software was easy to use and at no time did
we experience any difficulties in using the tool, nor did it lack features needed for
solving problems, so we do not find any objective reasons for the delegitimization
of the environment. It is possible that some students used it as a scapegoat for nor-
mal learning difficulties; for example, one student claimed that an up-to-date tech-
nology (in particular, a graphical interface) “would show us where the problem is.”
Culture clash. The dissatisfaction with CP was too widespread and too im-
mediate to attribute to any real deficiencies in the software, but it almost certainly
resulted from a lack of enthusiasm toward the old-fashioned interface. There was a
clash between the professional culture that readily accepts the necessity to work
with legacy systems and the user culture that emphasizes the interface.
From Culture Clash to FZCEs

These episodes of culture clash share similar characteristics with the description of
culture clash between teachers and educational researchers in Labaree (2003). Two
cultures are immersed in a zone of cultural encounter, but the encounter is not fer-
tile because both sides have a perspective that is productive for that side, so they
find it hard to legitimize the other perspective. Labaree’s approach is to narrow the
cultural divide:
Another approach … is to show that the gap is not as wide as it seems, that the differ-
ences are more a matter of emphasis in professional practice than of total opposition.
(p. 21)
We believe that the gaps we found were more than a matter of emphasis within a
practice. The user and professional perspectives share a goal of solving problems
with computers, but there is a wide gap in the standards as to what counts as a prob-
lem and the legitimization of practices to achieve a solution. Therefore, research-
ers must find a way to design pedagogical interventions that will enable students
and teacher to bridge the gap.
FERTILE ZONES OF CULTURAL ENCOUNTER
In order to construct a bridge between the two cultures, instruction should generate
an FCZE. Activities should be designed that are legitimate within students’ per-
spectives, but at the same time these activities should encourage students to realize
that the professional perspective is productive to achieving their goals and facili-
tate their participation in professional practices. In this section we describe how we
applied insights based upon culture clash to each of the situations described in the
previous section.
Resolving the Illegitimacy of the Professional Culture

We searched for a way to facilitate acceptance by the students of the norms of the
professional culture, in particular its definition of correctness. This we achieved by
constructing situations that gave a real-world meaning to each of the definitions of
correctness and facilitated negotiations between teachers and students on the
meaning of this concept. Here is a real-world version of the abstract synchroniza-
tion problem of the three operations described earlier (see Figure 2):
A software engineer was given the task of implementing a scheduling algorithm that
gives higher priority to programs submitted by faculty members than it gives to pro-
grams submitted by graduate or undergraduate students. His implementation gave
high priority to programs from faculty members, medium priority to programs from
graduate students and low priority to programs from undergraduate students. After
the undergraduate students complained, the department asked the engineer to modify
the program so that graduate and undergraduate students received the same priority.
The engineer claimed that he had correctly fulfilled the software requirements. Who
is correct?
Once the problem had been presented within the real world of computers, the
students were able to identify with the claims of both sides. During classroom dis-
cussion they were guided to recognize that the software engineer was—like many
of the students who chose solutions with unnecessary constraints in the abstract
problem—approaching the problem from the perspective of the user culture by
supplying a minimal solution. The department head expected the engineer to ap-
proach the problem from the norm of the professional culture that required that the
solution not add arbitrary constraints. In this context, the professional norm to
avoid unnecessary constraints looked less like pettiness and more like a useful
strategy.
Given that the concept of avoiding unnecessary constraints was not intuitive
and was unnatural within the students’ concept of “working” programs (because
such constraints are not visible to the person who executes the program), we in-
ferred that using informal language when discussing synchronization problems
was problematic. It caused ambiguity, allowing students to interpret synchroniza-
tion requirements in accordance with their idea of working programs. Therefore,
we decided to introduce a formal graphic notation for unambiguously specifying
synchronization requirements. The notation used the rectangles to represent pro-
cesses, and arrows (and dashed lines) to represent precedence (see Figures 1 and
2).2 This formal notation quickly became popular as a tool for the negotiation of re-
quirements specifications, because it proved to be clear and unambiguous. It was
used not only for the specification and design of new programs, but also for the
analysis of incorrect programs. In several cases we observed that students found it
difficult to analyze patently incorrect output until the teacher suggested that they
use the graphical notation.
In the following year, the example of the software engineer was presented be-
fore the problem of the three operations shown in Figure 2. On this problem, only
15% and 16% of 68 students chose the incorrect solutions A and B, respectively
(see Table 2). We also found an improvement in the students’ understanding of the
semaphore operations, from 53% correct answers to 64%. This we attributed to a
better definition of the operations (Ben-David Kolikant, 2004a), in addition to the
FZCE approach presented here.
This example shows how an FZCE works: The exercise was posed in language
that was culturally familiar, thus achieving legitimacy from the students, but the
negotiation it engendered facilitated their crossing the bridge toward understand-
ing the justification of the definitions used in the professional culture. The FZCE
resulted from the combination of the negotiation about the productivity of the pro-
fessional perspective together with the use of a cognitive tool (the notations) that
facilitated the students’ engagement in the professional practices.
The following conversation demonstrates the change in the nature of the dis-
course in the second year. It occurred as the class checked a homework assignment
2Each arrow in the figures represents the requirement that the operation at the base of the arrow pre-
cede the operation at the head of the arrow. Figure 2(b) shows the representation for the solution with
the unnecessary constraint that Op2 be executed before Op3, and similarly Figure 2(c) shows the repre-
sentation for the solution with the unnecessary constraint that the entire process E1 be executed before
both E2 and E3.
TABLE 2
Students’ Decisions and Reasoning on Correctness, Round 2 (n = 68)
Response
Solution B Solution C
Decision and Reasoning n % n %
Claim (incorrectly) that the solution is correct 10 15 11 16

The explanation includes recognition of the existence of the 8 12 7 10
unnecessary constraints, yet the student claims the solution
is correct because only good scenarios are possible.
The explanation includes the statement that solution is 2 3 4 6
correct because only good scenarios are possible; there is
no explicit recognition of the unnecessary constraints.
No explanation is provided. 0 0 0 0
Claim the solution is incorrect but the justification is wrong 0 0 5 8
Unexplained claim that a bad scenario can happen. 0 0 0 0
Incorrect assumption concerning the computational model. 0 0 0 0
Misunderstanding of the synchronization requirement. 0 0 5 8
Misunderstanding of the semaphore. 0 0 0 0
Correct decision and explanation 58 85 53 76
Total 68 100 68 100
concerning critical section problems. The teacher asked them how they knew that
their solutions were correct:
S1: When the program is incorrect then it is easy; you bring one example
that shows that the program doesn’t work.
Teacher: Yes. That is simple, but how will you show that it does work?
S2: If it is impossible to show a bad scenario.
Teacher: So, you go over all the scenarios to prove there is no bad one.
S3: This is not possible.
Teacher: It is not practical.
S4: We need to do it logically. [The student suggests going through all the
scenarios of a reduced problem.]
S5: The synchronization defect can only occur between these two operations
[of the critical section]. We should think of the scenarios there and show
nothing bad can happen.
The students carried out the discussion using the term scenarios that is characteris-
tic of the professional perspective because it is defined in the underlying computa-
tional model. In this situation, correctness was not discussed from the user per-
spective (in terms of the interface). In other situations the user perspective was
evident; however, this did not bring about delegitimization of the professional per-
spective. For example, after a laboratory session in which the teacher recognized
that some students were using F’s testing technique (running the program and not
checking the output), she brought the issue before the class, pointing out the “there
is no point in executing a program if you do not know what output to expect.” The
class laughed in agreement and then turned to analyze the assignment from a pro-
fessional perspective.
Resolving the Legitimacy of Abstract Knowledge

In order to gain the students’ appreciation of abstract problems as well their under-
standing of their importance within professional practice, we reorganized the se-
quence of presentation of problems. We began with real-world systems that were
culturally familiar to the students, such as automatic teller machines (ATMs), of-
fices selling tickets for concerts, and bank accounts. Eventually, the students real-
ized that these problems can be generalized to an abstract pattern, and that this pat-
tern is a powerful tool for solving problems, as one can reuse and adapt the solution
of the pattern in order to solve a specific problem. Gradually, as their repertoire of
patterns expanded, they came to appreciate the usefulness and significance of the
abstract approach of the professional culture. We could then introduce new ab-
stract problems and ask students to solve them.
At this point the students were able to appreciate the dining philosophers prob-
lem for what it is—a metaphorical abstract problem that encapsulates many con-
crete problems—and they were able to solve it within different computational
models. Later in the course when a different abstract problem was discussed, some
students reused the solution to the dining philosophers problem when solving the
new problem.
The following conversation demonstrates the change in students’ approach to
synchronization problems that were posed during the second year. The problem in-
volved concurrent access to ATMs. After the teacher presented the problem in a
real-world context, she gradually reduced the requirements and eventually her
bank had only one account and two ATMs. Although the simplified problem
amused the students, they willingly engaged in an analysis of the problem:
S2: What is the problem, then? We need to implement the actions [withdraw
and balance checking]. [There is a] synchronization problem here?
Maybe?
Teacher: Let’s say that T [one of the students] approaches one ATM.
S3: [interrupting] It [the ATM] asks “What do you want to do?” Oh, wait,
there is a synchronization problem here.
Teacher: OK, then maybe before starting the implementation we should think
about the requirements.
S4: [The requirement is] when someone uses one ATM the second ATM
should be completely locked out.
Teacher: You mean the operations of reading and writing the balance, or [locked]
for everything.
S4: For everything.
S5: Why? It doesn’t hurt if two persons read the balance simultaneously.
S5 critiques the exaggerated synchronization requirement suggested by S4, al-

though both solutions “work” from a user perspective. During the second year,
such conversations—in which the students’ analysis of the problems was firmly
based upon the requirements—were common.
In addition to reorganizing the sequence of the problems posed, our awareness
of students’ work preferences guided our design of each problem so that it would
encourage them to experience the productivity and the limitations of both the user
and the professional perspectives. For example, we wrote a concurrent program
that implemented a simplistic game in which one has to launch a missile to shoot
down an alien. The synchronization requirements in our program were correctly
fulfilled. Then we asked the students to extend the program to allow two missiles to
be launched.
Our assumption was that the goal of the task—generating a computer game—
would be legitimized by the students. Indeed, in the class that was observed, most
of the students even invested their free time until they successfully solved the prob-
lem. Additionally, we conjectured that the students who were used to living on the
interface would simply cut and paste the code for one missile to implement the sec-
ond missile. The activity was designed so that this naïve approach would not work
and the incorrect behavior would be immediately evident while executing the pro-
gram. This would require the students to specify the synchronization requirements
and to implement a solution within the formal model, thus engaging in the prac-
tices of the professional culture.
The idea of using intrinsically interesting exercises like games is not new to CS
education; these types of exercises have been proposed as a means of increasing stu-
dent motivation and of integrating a wide variety of programming techniques
(Sweedyk, deLaet, Slattery, & Kuffner, 2005). What is new was our attribution of the
success of this idea to achieving legitimacy among the students, and to the careful
design of the activities to require the use of methods from the professional culture.
We designed this FZCE in order to create two bridges: a bridge from concrete to
abstract problems built by carefully sequencing problems, and a bridge from the
user to professional practice built by purposeful design of problems.
Bridging Cultures With a Software Tool

We realized that providing the students with a concurrency simulator based upon a
graphical user interface was essential to bridging the cultural gap, even if there was
no pedagogical added value from its use. Therefore, jBACI, a functionally identi-
cal concurrency simulator with a modern graphical user interface, was developed.3
From the point of view of the students, the modern interface gave jBACI a legiti-
macy that the old simulator CP lacked. From our point of view and that of the
teachers, jBACI presented the same detailed data on the internal state of the pro-
gram and allowed the same fine level of control over the program execution, so that
jBACI could be used in the formal analysis of programs as required by the profes-
sional culture. The jBACI software functions as an FZCE: By providing an envi-
ronment with a graphical user interface, we legitimized the students’ strong prefer-
ence to work with such an environment, while the same functionality enabled them
to engage in the practices of the professional culture.
The Role of the Teachers

Teachers play an important role in facilitating the crossing of the bridge between
cultures. Teachers who are aware of the notion of culture clash can prompt stu-
dents’ learning, as demonstrated by F’s teacher. She and F used a similar vocabu-
lary to described different actions. The student’s response to the teacher’s question
“Did you check it?” (Line 2) was affirmative, although in fact the meanings that the
teacher and the students ascribed to “checking” were different. The teacher then
negotiated the professional meaning of checking a program. Her question “Is it the
output you were expecting?” pointed the student in the direction of the profes-
sional practice. It also prompted the student to accept that he had a problem and
that his current practice did not bring him closer to solving the problem. The fact
that the student later came to the teacher’s desk and explained—without being
asked—the problem he had had, this time using terminology appropriate to the
professional culture, implies that he had realized that employing the professional
practices was productive.
This shows how teachers can generate an FZCE: By helping students tune their
perspective in a problematic situation, teachers make professional practices acces-
sible and useful so that the students can experience their productivity.
CONCLUSION
The sociocultural framework shifted our emphasis from the content of students’
existing and newly constructed knowledge to the processes by which students ap-
3jBACI was built from the BACI (Ben-Ari Concurrent Interpreter) system (Bynum & Camp, 1996).
BACI is a total reimplementation and extension of the concurrency simulator described in Ben-Ari
(1982). Strite and Null (2002) wrote a portable interpreter with a graphical user interface in Java, which
we expanded into a full development environment. The source and executable code of jBACI, together
with documentation and sample programs, can be freely downloaded from http://stwww.weizmann.
ac.il/g-cs/benari/jbaci/index.html.
proach educational activities. Our inclusion of the theoretical metaphor of learning

as participation was inspired by the work done by Lave and Wenger (1991). But le-
gitimacy as used by Lave and Wenger is unidirectional: Old-timers legitimize new-
comers, and most instructional models based on this theoretical framework follow
their lead. For example, in cognitive apprenticeship as implemented by Schoenfeld
(1992), it is clear that Schoenfeld was the expert legitimizing the work of the stu-
dents and that they automatically legitimized the activities that he proposed.
In contrast, we found that CS students assert and exercise rights to grant legiti-
macy to activities proposed by the teachers and will not make the effort needed to
learn advanced subjects until such legitimacy has been granted. We believe that the
standing of teachers in CS is different from teachers’ standing in other subjects:
Students challenge the demands set by the teachers because they know how to pro-
ductively solve problems on the computer, although they have different ideas on
what counts as a satisfactory solution. We say that students are old-timers but in a
different culture, albeit one that is intertwined with the CS culture that the teacher
represents.
We conclude that it is productive to view CS education as an encounter between
two intertwined cultures, and this has led us to design pedagogical interventions as
FZCEs, which strive to make visible the distinction between professional and user
perspectives. The encounter zone is designed to look familiar to the student, thus
inviting legitimacy; at the same time, the intervention enables the student to per-
ceive that the user perspective is limited and that the professional perspective is
productive and accessible, thus facilitating crossing the bridge.
We believe that the concept of culture clash and FZCE is relevant to the entire
enterprise of CS education, not just to the topic of concurrent programming. For
example, a very painful issue that each institution faces is deciding which pro-
gramming language to use in teaching introductory courses. Educators who wish
to convey the scientific principles of computation prefer simple programming lan-
guages in order to avoid unnecessary distractions (Gries, 2002), whereas students
prefer to learn the languages perceived as state of the art. The framework of culture
clash provides a reasonable explanation for the students’ attitude. Just as we en-
countered resistance to the use of our original environment, one can expect to en-
counter resistance if a programming language is taught that is not consistent with
the students’ productive experience using modern software. Educators choosing a
programming language must be sensitive to this aspect of the students’ culture and
either accede to their wishes or negotiate an agreement to use another language
while recognizing the perspective of the students. (See Ben-Ari, 2004, for a discus-
sion of this and similar issues.)
The central position of computers in all fields of study implies that our findings
can be broadly relevant. There is no question that working with computers pro-
vides new capabilities for learning, such as running simulations of complex physi-
cal systems, but educators must be aware of the cultural perspective and practices
of the students. For example, when solving a problem in a simulation environment,

students might focus their efforts on the interface in order to achieve a working so-
lution, without engaging in the learning experience that the teacher intended. The
notion of culture clash can contribute to understanding such learning difficulties,
and interventions designed on the principles of FZCEs can help overcome them by
respecting the students’ perspective while at the same time facilitating their en-
gagement in professional practices.
APPENDIX: THE DINING PHILOSOPHERS PROBLEM
The dining philosophers problem, invented by the late Edsger W. Dijkstra, is an ex-
ample of an important problem in concurrency that concerns the exclusive alloca-
tion of resources in a multi-entity system. The statement of the problem is as fol-
lows:
Five philosophers spend their lives alternately thinking and eating. They are seated in
a room around a circular table, with a single fork placed between each pair of neigh-
boring philosophers. In the middle of the table is an (inexhaustible) bowl of spa-
ghetti. When a philosopher wishes to eat, she must be in possession of both forks.
Good manners require that a philosopher pick up only one fork at a time. Develop an
algorithm for the philosophers that satisfies the following requirements: (a) mutual
exclusion (at most one philosopher is in possession of any fork at any time), (b) no
deadlock (if several philosophers wish to eat, eventually, one of them does so), (c) no
starvation (any philosopher wishing to eat eventually does so).
There is no fully satisfactory solution to this problem. Solutions to this problem in-
clude (a) an asymmetric solution (in which one philosopher picks up her forks in a
different order than do her colleagues), (b) a solution with extra overhead (a door-
man who ensures that at most four philosophers try to eat simultaneously), and (c)
an algorithm that uses randomness. The research and pedagogical attractiveness of
this problem stems from the depth of the conceptual and technical issues that can
be discussed within its entertaining framework.
REFERENCES
Aho, A. V., & Ullman, J. D. (1992). Foundations of computer science. New York: Freeman/Computer
Science Press.
Ben-Ari, M. (1982). Principles of concurrent and distributed programming. London: Prentice Hall In-
ternational.
Ben-Ari, M. (2001). Constructivism in computer science education. Journal of Computers in Mathe-
matics and Science Teaching, 20(1), 45–73.
Ben-Ari, M. (2004). Situated learning in computer science education. Computer Science Education,
14, 85–100.
Ben-Ari, M., & Ben-David Kolikant, Y. (1999). Thinking parallel: The process of learning con-
currency. SIGCSE Bulletin, 31(3), 13–16.
Ben-David Kolikant, Y. (2001). Gardeners and cinema tickets: High school students’ preconceptions of
concurrency. Computer Science Education, 11, 221–245.
Ben-David Kolikant, Y. (2004a). Learning concurrency: Evolution of students’ understanding of syn-
chronization. International Journal of Human Computers Studies, 60(2), 243–268.
Ben-David Kolikant, Y. (2004b). Learning concurrency as an entry point to the community of CS prac-
titioners. Journal of Computers in Mathematics and Science Teaching, 23(1), 21–46.
Ben-David Kolikant, Y., Ben-Ari, M., & Pollack, S. (2000). The anthropology of semaphores. SIGCSE
Bulletin, 32(3), 21–24.
Booth, S. (2001, August). Learning to program as entering the datalogical culture: A phenomeno-
graphic exploration. Paper presented at the Ninth European Association for Research on Learning
and Instruction Conference, Fribourg, Switzerland. Retrieved December 13, 2006, from http://
www.pedagog.lu.se/personal/sb/Entering%20the%20datalogical%20culture.pdf
Brown, B. A. (2004). Discursive identity: Assimilation into the culture of science and its implications
for minority students. Journal of Research in Science Teaching, 41, 810–834.
Brown, J. S., Collins, A., & Duguid, P. (1989). Situated learning and the culture of learning. Education
Researcher, 18(1), 32–42.
Bynum, B., & Camp, T. (1996). After you, Alfonse: A mutual exclusion toolkit. SIGCSE Bulletin,
28(1), 170–174.
Carroll, J. M., & Rosson, M. B. (1987). The paradox of the active user. In J. M. Carroll (Ed.), Inter-
facing thought: Cognitive aspects of human-computer interaction (pp. 80–111). Cambridge, MA:
MIT Press/Bradford Books.
Clark, M. A. C., & Boyle, R. D. (1999). A personal theory of teaching computing through final year
projects. Computer Science Education, 9, 200–214.
College Board AP. (2006). Computer science: Course description. Retrieved December 13, 2006, from
http://apcentral.collegeboard.com/repository/05834apcoursdesccomps_4315.pdf
Davies, S. P. (1993). Models and theories of programming strategy. International Journal of Man-Ma-
chine Studies, 39, 237–267.
Edwards, S. H. (2004). Using software testing to move students from trial-and-error to reflection-in-ac-
tion. SIGCSE Bulletin, 36(1), 26–30.
Gal-Ezer, J., Beeri, C., Harel, D., & Yehudai, A. (1995). A high-school program in computer science.
IEEE Computer, 28(10), 73–80.
Goodell, H., Maulsby, D., Kuhn, S., & Traynor, C. (1999). End-user programming/informal program-
ming. A workshop conducted at the ACM CHI 1999. SIGCHI Bulletin, 31(4), 17–21. Retrieved De-
cember 8, 2006, from
Gries, D. (2002). Where is programming methodology these days? Inroads SIGCSE Bulletin, 34(4),
5–7.
Gutiérrez, K., & Rogoff, B. (2003). Cultural ways of learning: Individual traits or repertoires of prac-
tice. Educational Researcher, 32(5), 19–25.
Hartmanis, J. (1995). Turing award lecture: On computational complexity and the nature of computer
science. Computing Surveys, 27(1), 7–16.
Hoare, C. A. R. (1989). Computer science. In C. A. R. Hoare & C. B Jones (Eds.), Essays in computing
science (pp. 89–101). Englewood Cliffs, NJ: Prentice Hall.
Holmboe, C. (2004). A Wittgenstein approach to the learning of OO-modeling. Computer Science Edu-
cation, 14, 277–296.
Holmboe, C. (2005).Conceptualization and labelling as cognitive challenges for students of data mod-
eling. Computer Science Education, 15, 143–161.
Holmboe, C., McIver, G. C., & George, C. (2001). Research agenda for computer science education. In
G. Kadoda (Ed.), Proceeding of the 13rd Annual Meeting of the Psychology of Programming Interest
Group (pp. 207–223). Bournemouth, UK: Bournemouth University.
Hundhausen, C. (2002). Ethnographic studies of a social constructivist approach to integrating algo-
rithm visualization technology into an undergraduate algorithms course. Computers & Education,
39(3), 237–260.
Knuth, D. (1974). Computer science and its relation to mathematics. American Mathematical Monthly,
81, 323–343.
Knuth, D. (1985). Algorithmic thinking and mathematical thinking. American Mathematical Monthly,
92, 170–181.
Labaree, D. F. (2003). The peculiar problems of preparing and becoming educational researchers. Edu-
cational Researcher, 32(4), 13–22.
Lave, J., & Wenger, E. (1991). Situated learning: Legitimate peripheral participation. Cambridge,
England: Cambridge University Press.
Leventhal, L. M., Teaslley, B. E., & Schertler Rohlman, D. (1994). Analyses of factors related to
positive test bias in software testing. International Journal of Human Computer Studies, 41,
717–749.
McCracken, M., et al. (2001). A multi-national, multi-institutional study of assessment of program-
ming skills of first-year CS students. SIGCSE Bulletin, 33(4), 125–140.
Nardi, B., & Miller, J. (1991). Twinkling lights and nested loops: Distributed problem solving and
spreadsheet development. International Journal of Man-Machine Studies, 34, 161–184.
Nardi, B. A. (1993). . Cambridge, MA: .
Neumann, A., Pallas, A., & Peterson, P. (1999). Preparing education practitioners to practice education
research. In E. C. Lagemann & L. S. Shulman (Eds.), Issues in education research: Problems and
possibilities (pp. 247–288). San Francisco: Jossey-Bass.
Resnick, L. B. (1989). Knowing, learning, and instruction: Essays in honor of Robert Glaser. Hillsdale,
NJ: Erlbaum.
Rist, R. S. (1995). Program structure and design. Cognitive Science, 19, 507–562.
Roberts, E. (2004). The dream of a common language: The search for simplicity and stability in com-
puter science education. SIGCSE Bulletin, 36(1), 115–119.
Robins, A., Rountree, J., & Rountree, N. (2003). Learning and teaching programming: A review and
discussion. Computer Science Education, 13, 137–172.
Rosebery, A., Warren, B., & Conant, F. (1992). Appropriating scientific discourse: Findings from lan-
guage minority classrooms. Journal of the Learning Sciences, 2, 61–94.
Roth, W.-M., & Bowen, G. M. (1995). Knowing and interacting: A study of culture, practices, and re-
sources in a grade 8 open-inquiry science classroom guided by a cognitive apprenticeship metaphor.
Cognition and Instruction, 13, 73–128.
Schoenfeld, A. H. (1992). Learning to think mathematically: Problem solving, metacognition, and
sense-making in mathematics. In D. Grouws (Ed.), Handbook for research on mathematics teaching
and learning (pp. 334–370). New York: Macmillan.
Schofield, J. W. (1995). Computers and classroom culture. New York: Cambridge University Press.
Sfard, A. (1998). On two metaphors for learning and on the dangers of choosing just one. Educational
Researcher, 27(2), 4–13.
Simon, B. Lister, R., & Fincher, S. (2006). Multi-institutional computer science educational research:
A review of recent studies of novice understanding. Proceedings of the 36th Annual Frontiers in Edu-
cation Conference, SE412–17.
Smith, J. P., III, diSessa, A. A., & Roschelle, J. (1993/1994). Misconceptions reconceived: A con-
structivist analysis of knowledge in transition. Journal of the Learning Sciences, 3, 115–164.
Soloway, E., & Spohrer, J. C. (Eds.) (1989). Studying the novice programmer. Hillsdale, NJ: Lawrence
Erlbaum.
Strite, D., & Null, L. (2002). BACI debugger: A GUI debugger for the BACI system. Journal of Com-
puting Sciences in Colleges, 17(4), 112–122.
Sweedyk, E., deLaet, M., Slattery, M. C., & Kuffner, J. (2005). Computer games and CS education:
Why and how. SIGCSE Bulletin, 37(1), 256–257.
Turkle, S. (1995). Life on the screen: Identity in the age of the Internet. New York: Simon & Schuster.
Warren, B., Ballenger, C., Ogonowski, M., Rosebery, A. S., & Hudicourt-Barnes, J. (2001). Rethinking
diversity in learning science: The logic of everyday sense-making. Journal of Research in Science
Teaching, 38, 529–552.
Wenger, E. (1998). Communities of practice—Learning, meaning and identity. Cambridge, England:
Cambridge University Press.
Wiedenbeck, S., Ramalingam, V., Sarasamma, S., & Corritore, C. L. (1999). A comparison of the com-
prehension of object-oriented and procedural programs by novice programmers. Interacting with
Computers, 11, 255–282.
View publication stats

Fertile Zones of Cultural Encounter in Computer Science Education

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fertile Zones of Cultural Encounter in Computer Science Education

Uploaded by

Copyright:

Available Formats

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Fertile Zones of Cultural Encounter in Computer Science Education

Article in Journal of the Learning Sciences · February 2008

Yifat Ben-David Kolikant Mordechai Ben-Ari

SEE PROFILE SEE PROFILE

Computer-science education as a cultural encounter View project

Non-determinism in CS View project

The user has requested enhancement of the downloaded file.

Journal of the Learning Sciences

Online Publication Date: 01 January 2008

PLEASE SCROLL DOWN FOR ARTICLE

Full terms and conditions of use: http://www.informaworld.com/terms-and-conditions-of-access.pdf

Fertile Zones of Cultural Encounter

We explain certain learning difficulties in computer science education as resulting

SURVEY OF PREVIOUS WORK

Cognitive and Sociocultural Frameworks

essarily preferred, perspective. Labaree, in contrast, saw the researchers’ perspec-

Two Cultures in Computing

1. The cultures are distinguished by their judgment as to what counts as a

Users appreciate a development process based upon exploring technologi-

The CS Classroom as an Arena for Culture Clash

The wealth of findings regarding students’ alleged shallow behavior (e.g.,

OUR PREVIOUS WORK

students are introduced to fundamental synchronization problems in various com-

Summary of the Results of the Research

book, and the laboratory environment (Smith et al., 1993/1994). Specifically, we

such as semaphores without identifying the requirements of synchronization). Ac-

Y: [pointing to two lines of unexpected output] The question is what do they

ATTRIBUTING LEARNING DIFFICULTIES

The CS culture clash is presented by describing three types of learning difficulties

• Expectation: the expected outcome in terms of the professional perspective;

The Definition of Correctness

FIGURE 2 Solutions offered in Test A. E = entity; Op = operation.

Expectation. The expected outcome—as explicitly required in the statement

Learning difficulties. The analysis of the students’ answers is presented in

Decision and Reasoning n % n %

Claim (incorrectly) that the solution is correct 51 37 56 41

S1: The solution is OK.

Teacher: Yet, when a programmer is asked to write a program to do A and B and

Learning difficulties. Here is the exchange between F and the teacher:

1. F: That’s it. [Hands in the printout and the lab report.]

Culture Clash in Software Technology

Expectation. We were aware that the students—used to modern software

Learning difficulties. The CP concurrency simulator was not readily ac-

From Culture Clash to FZCEs

FERTILE ZONES OF CULTURAL ENCOUNTER

Resolving the Illegitimacy of the Professional Culture

Decision and Reasoning n % n %

Claim (incorrectly) that the solution is correct 10 15 11 16

Resolving the Legitimacy of Abstract Knowledge

S5 critiques the exaggerated synchronization requirement suggested by S4, al-

Bridging Cultures With a Software Tool

The Role of the Teachers

proach educational activities. Our inclusion of the theoretical metaphor of learning

of the students. For example, when solving a problem in a simulation environment,

APPENDIX: THE DINING PHILOSOPHERS PROBLEM

View publication stats

You might also like