Introduction
Introduction
and Background
This suburban high school, which combined two existing high
schools, first opened its doors in the fall of 1957 with 300
students in grades 9 through 12. There were 45 juniors, 86
sophomores, and 114 freshmen. The faculty consisted of 13
members, including the principal. The first graduation ceremony
was held in the gym of the high school with 55 students receiving
diplomas. At that time, the school was 100% White.
The high school currently has 2,207 students; and over the
last few years, the school has experienced an increase in
the African-American, Hispanic, and other minority populations
(see Figure 1). The percentage of students receiving free
and reduced lunch has also increased markedly over the past
few years (see Figure 2).

Figure
1. Percentage of enrollment by race.

Figure
2. Students eligible for free and reduced meals
Statement
of the Problem
One of the courses I teach is A.P. Computer Science. However,
with a minimum enrollment of 14, it does not always get offered
(e.g., last year, there were only eight students). In an effort
to create interest in the A.P. Computer Science course, I
went from classroom to classroom to recruit potential students.
I spoke about how Java is used in robotics and even showed
them a video of a robot made with LEGO® bricks and programmed
with a Java based operating system. My main focus was mainly
those students in College Prep Algebra II, Honors/Gifted Algebra
II, Pre-calculus, and Visual Basic. I had more than 25 students
fill out an application, but only 14 of those students fulfilled
the requirements of successfully completing Algebra I or its
equivalent with a grade of B or higher, and a teacher’s
recommendation. Two perks for the students are that the students
get 10 additional points added on to their class average at
the end of each semester, and if they receive a high enough
qualifying score on the A.P. exam in May 2005, they could
possibly get college credit for an introductory computer science
course.
Even if the students did not necessarily want to exempt an
introductory computer science course, I think it’s important
for all students to have some programming experience –
especially those who are college bound. Programming helps
with honing problem-solving skills, developing efficient algorithms,
and logical thinking.
Many first year university students have found introductory
computer science courses frustrating to the point that many
of them drop out during the first semester ( McDowell, Werner,
Bullock, & Fernald, 2003). I have found this same phenomenon
at the high school in which I teach, in the Advanced Placement
(A.P.) Computer Science classes. The high school in which
this study was given is located in a suburb of Atlanta, Georgia.
According to the Accountability Report (Results-Based Evaluation
System) issued 2003 – 2004, the school's overall number
of students taking Advanced Placement (AP) tests increased,
but the total number of AP tests taken decreased along with
the number of students who scored a “3” or better
(see Figure 3).
| 1998-1999 |
1999-2000 |
2000-2001 |
2001-2002 |
2002-2003 |
| 58% |
59% |
57% |
51% |
49% |
Figure
3. Percent of advanced placement tests receiving a
score of 3 or higher
All
of the teachers at the high school who teach Advanced Placement
courses were asked to focus instruction on developing strategies
that will help the students achieve higher scores on the
next testing administration. Although the National Science
Foundation reported in 1997 that the top six careers for
the next ten years are in the computer field, there is little
interest in the A.P. Computer Science course by both male
and female students. Furthermore, in 2001, the enrollment
in the A.P. Computer Science class decreased from 21 students
to 7 students within the first month of the first semester
of school.
While searching the Web for possible teaching strategies
that have been used in other A.P. Computer Science classrooms
across the country as well as Canada, I found several that
I could incorporate into my class this year. Of these, there
was one strategy I found that is cutting edge, and hasn’t
typically been used in a high school classroom. It is called
“pair programming."
In a software development methodology called Extreme Programming
(XP), there is a component called “pair-programming”
(Beck, 2000). The pair programming dimension of XP requires
that two programmers work collaboratively at one computer
on all code, tests, algorithms, and design. One of the programmers,
known as the “driver” is in control of the pencil/mouse/keyboard.
The driver actively creates the code. The other programmer,
the “non-driver” or the “navigator”
has many responsibilities. The non-driver constantly observes
the keyed work to identify any tactical and strategic deficiencies,
including erroneous syntax and logic, misspelling, and implementations
that don’t map to the design (McDowell, 2003). After
a designated period of time, the partners reverse roles.
As educators, we often team students together for particular
tasks, but have seldom been willing to go beyond this. In
particular, we think of intellectual activity as being individual
and not shared. One theory presented by psychologist Lev
Vygotsky (1978) professes that learning is a social process
that does not happen by itself but instead occurs through
interaction with others.
In my research, I wanted to show that pair programming in
the A.P. Computer Science class would result in the students’
having a higher retention rate and a better quality of code
– based on the number of lines used. Furthermore,
I hypothesize that the students involved in the research
enjoyed working with the pair programming model, and will
be encouraged to pursue a career in the computer science
industry.
The goal of this experiment was to encourage students to
be responsible for each other’s learning and to determine
if this can be done effectively while achieving high student
satisfaction, as well as high academic success. The experiment
will report both statistical and non-statistical results.
While it will not give a definitive answer to the questions
posed, due to the small sample set, it will guide further
study.
Research Questions
The
purpose of my research is to answer the following questions:
- Do
the students enjoy working collaboratively on all of the
programming assignments
in the A.P. Computer Science course?
2. As a result of using the pair programming model in
the A.P. Computer Science course, will the students have
a higher retention rate and perform with at least a “C”
average?
- As
a result of using the pair programming model in the A.P.
Computer Science course, will the students have a higher
retention rate and perform with at least a “C”
average?
- Will
the students perform the roles of “driver”
and “navigator” as prescribed by the XP component
of pair programming effectively and without constant prompting?
Limitations
With any research studies, there are limitations. In my
study, the limitations were identified as:
- Small
sampling size (n = 14);
- No
control group vs. experimental group;
-
Only one Advanced Placement Computer Science class was
used in the study;
- This
was my first year teaching the A.P. course using the Java
programming language;
- One
of the original students got a schedule change to fulfill
a graduation requirement, and was replaced with a student
who needed a course during the class period this class
was offered.
- There
was not a diverse enough population of students in the
study. All but one of the students was White, and there
was only one female student involved.
- The
study did not last for the entire semester, so Final Exam
grades, Final course grades, and retention rates will
not be available.
Despite
the limitations of the study, I am sure that my study is
important and that the data is valuable because it shows
the importance of collaborative learning and the benefit
of learning by teaching.
Importance of Study
My goal was to show that using the pair-programming model
in the high school Advanced Placement Computer Science classroom
was beneficial to the students as well as the instructor.
Since most computer programmers in the current workforce
spend half of their time working with at least one other
person (Williams, Wiebe, Yang, Ferzli, & Miller, 2002),
it is important that the students get the experience of
true collaboration with someone. Since most of these students
involved in the study are planning on pursuing further education
or a career in the computer science field, it was an important
experience for them all.
Literature Review
My
Search for Resources
After meeting with the other Advanced Placement teachers at
South Gwinnett High School, I set out to find different ways
to drive instruction to improve A.P. Computer Science scores
and increase interest in the course. I used a popular search
engine (Google™) to look for websites that came up when
I typed in “A.P. Computer Science." I was looking
at an A.P. teacher’s website and came across a link
to A.P. Central, the official online home for anyone interested
in or involved in A.P. programs. On this site, I also registered
to be a member of the A.P. Computer Science listserv, which
is also hosted by The College Board. Using these two resources,
I discovered that several introductory computer science college
instructors have employed using a facet of Extreme Programming,
called “pair-programming.” This idea of having
the students work collaboratively on every aspect of programming
fascinated me. I then searched using “pair programming”
and “Extreme Programming” as my terms. Although
Extreme Programming is a fairly new concept, I was able to
find many articles that support the benefits of using pair-programming
in the classroom. There was only one article that spotlighted
using this model in a high school classroom.
I decided almost immediately that not only would I utilize
this model to potentially increase the A.P. test scores in
my discipline, I would also like to explore this topic as
the focus of my applied research project.
Theory
The registration rate for students in Advanced Placement Computer
Science courses has been steadily declining at this high School.
In fact, the last time this course was taught in 2002, the
original roster of 21 students had dwindled to 7 students
within the first 10 days of class. When the students who had
dropped the course were asked why, they said that they thought
that the course would be too hard and that they wouldn’t
have sufficient support with the programming assignments.
They also indicated that they didn’t have access to
the software used in class at their homes, and the productivity
labs available at school did not have this software loaded
on its computers either.
In recent years, the growth of extreme programming (XP) has
brought considerable attention to collaborative programming.
The pair programming dimension of XP requires that all programmers
work in teams, regardless of their skill levels or their experience.
This collaborative programming model has also been implemented
in many introductory level computer science courses in several
universities. It has been indicated that pair programming
provides the support that many students find effective in
a programming course. To acquire previous studies done on
pair programming, I typed “pair programming” into
a Google™ search. I also did a search of “Extreme
Programming” on the County Public library online database.
Both of these avenues provided me with a bevy of articles,
techniques and research to help answer my research questions.
In industry, it has been reported that software developers
generally spend 30% of their time working alone, 50% of their
time working with one other person, and 20% of their time
working with two or more people (Williams, Wiebe, Yang, Ferzli,
& Miller, 2002). Yet, in the high school computer science
courses, programmers learn to program alone; collaboration
is considered cheating. This time spent working alone unfortunately
conflicts with a student’s future professional life
in which collaboration is both encouraged and required. In
addition, studies show that cooperative and collaborative
pedagogies are beneficial for students (Ratcliffe & Robertson,
2003). In their 2003 research with beginning Object-Oriented
Programming students At the University of Wales, Ratcliffe
and Robertson discovered that collaborative learning had a
very positive impact on learning. The benefit comes from a
smaller knowledge barrier from student to student than that
from teacher to student. The series of experiments conducted
by Racliffe and Robertson also showed that overall the students
liked pair programming and believed that it helps them achieve
good solutions. Students with less self-confidence seemed
to enjoy pair programming the most.
Students have long been conditioned to working alone. Many
venture into their first pair programming experience skeptical
that they would benefit from collaborative work (Williams,
Kessler, Cunningham, & Jeffries, 2000). They wonder about
the added communication that will be required, about adjusting
to the other’s working habits, programming styles, ego,
and about disagreeing on aspects of the implementation. There
is an initial adjustment period in the transition from solitary
to collaborative programming. In industry, this adjustment
period has historically taken hours or days, depending upon
the individuals. At the university level, the students generally
adjusted after the first assignment, though some reported
an even shorter adjustment period. In an experiment involving
pair programming at the University of California, Santa Cruz,
555 students (414 men and 141 women) in an introductory computer
programming course were given Williams’ and Kessler’s
paper “All I Really Need to Know About Pair Programming
I Learned in Kindergarten” (Williams, & Kessler,
2000). After the students were given a brief one minute description
of pair programming, they were instructed to read the paper
as a homework assignment. After extensive analyses, the research
indicated that the paired students overwhelmingly perceived
that working collaboratively enhanced the quality of their
code and increased their understanding of the course material
(McDowell, Werner, Bullock, & Fernald, 2003). Making the
transition to pair programming involves breaking down some
personal barriers beginning with the understanding that talking
is not cheating. First, the students must understand that
the benefits of intercommunication outweigh their common (perhaps
innate) preference for working alone (Williams, 1999). Secondly,
they must confidently share their work, accepting instruction
and suggestions for improvement in order to advance their
own skills and the product at hand.
How Personality Types and Learning Styles Effect Pair-Programming
In examining the relationship of personality types and computer
programming, research indicates that while personality may
have little to do with overall achievement in computer programming
classes, it may be more closely related to achievement on
one of the components of the class grade – programming
assignments (Bishop-Clark, & Wheeler, 1994). The four
driving hypotheses in this study were:
1) Introverts
will have a higher program average than Extroverts;
2) Sensors will have a higher program average than Intuitives;
3) Judgers will have a higher program average than Perceptives;
and
4) Thinkers are more likely to complete the class then Feelers.
Another significant finding from this study was that active
and visual learners did not do as well in the role of “navigator”
in the pair programming model. I was also interested in learning
whether pairing a female student with a male student would
be disruptive to the learning process, or a benefit.
One of the reasons we are doing a poor job at getting and
keeping students in A.P. Computer Science is that we as educators
are using an out-dated view of computing and students (Guzdial,
2000). Many of us teach computer science in much the same
way we learned it. The activities we learned with matched
the available computing hardware. Computing today is much
different, and offers many more opportunities for us to deliver
instruction. Pair programming is a model designed for industry,
but may attract a group of students that would not be excited
by the abstract, text world we grew up with.
Pair programming is being used in most of the introductory
computer science courses at North Carolina State University
and at The University of Utah. In 1999, a controlled experiment
was run at North Carolina State University to investigate
the effectiveness in terms of satisfaction of pair programming
(Cockburn, & Williams, 2000). Using surveys and questionnaires,
the investigators found that the students working in pairs
found the experience more enjoyable than working alone. In
this study, the class was divided into two groups: and “individual”
group in which solo programmers did all programming, and a
“collaborative” group in which all programming
was done in pairs. In each programming cycle, the individuals
were given one program to complete while the pairs were given
two programs to complete. When one group complained that this
arrangement was unfair, the instructor offered that they split
up and work as solo programmers. Both students rejected this
offer almost instantaneously. In a subsequent experiment at
North Carolina State University by the second researcher,
74% of the students noted “between my partner and I,
we could figure everything out” (p. 08) 63% noted that
“it was the pair-pressure – I could not let my
partner down” (p. 12) Overall, 95% of the class agreed
with the statement “I was more confident in our assignments
because we pair programmed” (p. 12) This shows a strong
indicator of the satisfaction of pair programming.
The modified pair programming model that will be used will
involve the students’ taking their quizzes and tests
independently. Only the programming assignments will be worked
on collaboratively. One key element is that while working
in pairs, ideally, a continuous code review is reviewed. This
aspect of pair programming teaches the students to review
their work and make adjustments in design individually as
well (Williams & Kessler, 2001).
Another sub-problem I intended to examine was the under-representation
of female students in the computer science field. According
to the College Board, the percent of female students taking
the A.P. Computer Science exam has only increased by 1% (15%
to 16%), from 1986 to 2002. Women receive less than 28% of
the computer science bachelor’s degrees, down from a
high of 37% in 1984. Computer science is the only field in
which women’s participation has decreased over time
(Hill, 2001). In an effort to increase math test scores and
close a nationwide math achievement gap that finds girls trailing
behind boys from elementary school through high school, the
Indian River school district in Delaware, aided by additional
funds provided by the “No Child Left Behind” Act,
decided to teach boys and girls in separate classrooms. What
they found is that the girls learned better in a collaborative
setting. Additionally, they found that most of the girls were
visual learners who thrived on using hands-on manipulatives.
In my research, I attempted to draw similar conclusions. I
was interested in whether or not the pair programming model
will enhance the learning experience for the female students
who had initially registered for the course. If the conclusions
in my experiment were similar to the experiment in the Indian
River school district, then the girls in the A.P. Computer
Science class will be more successful, and enjoy the coursework
more when they are paired with each other.
Summary
The existing literature provides some of the most compelling
evidence that pair programming is effective as a pedagogical
tool. It appears that pairing bolsters course completion and
consequently course pass rates, and contributes to greater
persistence in computer science related majors.
The continued under-representation of women in computer science
underscores the need for strategies that foster women’s
interest and promote their success (AAUW, 2000). Pair programming
appears to be one such approach. That the benefits associated
with pair programming extend to both male and female students
speaks to its broad-based appeal. As I continue to investigate
the effects of this technique on attracting and retaining
female students, parallel research investigating these phenomena
in the workplace is also needed.
The
use of pair programming may take the instructor out of their
“comfort zone” because the need to deal with additional
issues such as one partner ending up with all of the work,
how to distribute grades, etc. The technique deserves further
research. However, it has the potential of changing how classes
are taught in order to benefit the students’ learning
experience.
Methods
Methodology
Participants
The participants in this experiment are 14 Advanced Placement
Computer Science students (13 males and 1 female). One student
is in the 10th grade, one student is in the 11th grade, and
the remaining students are in the 12th grade. All but one
of the students are White; the other student is African-American.
The only female student is White.
All but one of these students was recommended to take this
course. The prerequisites for the course were: at least a
“B” average in Algebra I, and a teacher recommendation.
The only student who was not recommended to take the course
had gotten a schedule change during the week prior to the
beginning of school and was asked if he thought he would like
to take this course since it was the only one that fit his
schedule.
Instruments
Procedure
Quantitatively, I used quiz and test scores to examine my
assumption that pair-
programming will reinforce terms and concepts for the students,
and result in them achieving at least a “C” average.
Several of the quizzes that were administered to the students
were vocabulary quizzes. The students not only had to define
words and terms taught in class; they also had to provide
an example of the word or term. Another type of quiz that
was given comprised of a problem description and the code
that will solve the problem – with some of the lines
missing. The students have to fill in the missing lines that
would complete the code. The tests were more comprehensive,
in that the students were required to write complete, short
programs that were run and tested afterwards, as well as answer
short answer questions that were designed to look similar
to questions provided on the A.P. Computer Science exam. Qualitatively,
I used surveys, anonymous journal questions, and observation
to examine my assumption that pair programming will be an
enjoyable experience for the students, and will encourage
them to pursue further studies in computer science. The questions
asked on the surveys were designed to assess whether or not
they were enjoying participating in the pair-programming model.
The blogs were used as a means for the students to assess
the pair-programming model, their partners, and the coursework.
This study progressed over the period of the first eleven
weeks of the first semester of the academic school year. There
was at least one programming assignment assigned bi-weekly
and a minimum of one quiz per week, and four major tests.
First, I was required to obtain approval from the county and
my local school principal (see Appendix B.) Then I applied
for approval from the University of Georgia’s Institutional
Review Board (IRB) (see Appendix A.), since I was using human
subjects in my research. I received written approval
from both the county and from the Institutional Review Board.
On the first day of school, all of the students in the Advanced
Placement (A.P.) Computer Science course were given permission
forms for their parents to complete and return (Appendix C.)
Since I had two students who were 18, I also gave these students
a Consent Form to complete and return the next day as well
(Appendix D). The other students, who were younger than 18,
were given Assent Forms to complete and return (Appendix E).
All of these forms briefly explained the philosophy of the
“pair-programming” model and gave me permission
to include the students in the study as well as using student
samples as data in my research. All of forms were completed
and returned the next day and filed away in a secure file
cabinet in my office located behind my classroom at school.
Within the first week of school, all of the students were
given the assignment to create a website onto which they would
post links to the text files that housed their homework assignments.
Some of the students already had websites, and just had to
create a new link for the A.P. assignments. The other students
were given class time to create a website using one of the
free web host servers (ie – Tripod, Yahoo, Lycos, etc.).
There were several students who had no experience with creation
and maintenance of a website, so we spent a day learning basic
HTML tags so they could link their assignments. The first
assignment was to link a test page to their website. All of
the students were able to link this text file to their site.
I asked the students to use a .txt or a .html extension on
all of their homework assignments, so I could easily cut and
paste their code into BlueJ, the Java IDE that the county
approved for use in the Advanced Placement Computer Science
classroom. I stressed that the website was to be merely a
source onto which assignments would be posted. I didn’t
want them to worry about “designing” the website
and lose focus on the actual Java programming assignments.
It could be as simple as a plain page with a series of links
on it. A screenshot of two student assignment websites is
shown in Appendix F.
The students were also told to create a web-based journal
(blog) that was just to be used for the purposes of answering
journal questions for this course. I gave the students the
URL for a free blog hosting service, and they created their
blogs during classtime. Once they were done; they gave me
the addresses of their blogs so I could have access to their
journals at all times. At various times during this study,
the students were asked to reflect upon their experiences
in the course, in terms of utilizing the “pair-programming”
model in learning the A.P. Computer Science curriculum. I
plan to use the responses in the journal entries to help guide
my instruction with this class and future A.P. Computer Science
courses that I will teach.
To further facilitate the qualitative research aspect of my
study, I used an Observation Log (Appendix G) to jot down
what the students were doing during the class periods. Each
class period is 53 minutes long. I tried to maintain the log
either during the class period; during the seven minutes after
this class and before the next class; or during my planning
period. I made notes in my log at random times during the
study so I could have a sampling of observations on different
days of the week, not just on the same day of the week.
Getting Started with the Research
On the first day of class, the students were given Williams’
and Kessler’s paper “All I Really Need to Know
About Pair Programming I Learned in Kindergarten” to
read as a homework assignment. This article was used to introduce
the students to the concept of pair programming, and what
the “rules” of pair programming are. I spoke very
briefly about how the course would be conducted, but was purposely
vague about the collaborative efforts they all would make
this year. A very short quiz was given the following day about
the article. The quiz was administered during the first 10
minutes of class. The students had to choose three of the
following statements and write a short description of what
the statement means, in terms of pair programming.
1. Share
everything.
2. Play fair.
3. Don’t hit your partner.
4. Put things back where they belong.
5. Clean up your mess.
6. Don’t take things too seriously.
7. Say you’re sorry when you hurt somebody while moving
furniture
8. Wash your hands of skepticism before you start.
9. Flush.
10. Warm cookies and cold milk are good for you.
11. Live a balanced life – learn some and think some
and draw and paint and sing and dance and play and work ever
day some.
12. Take a break from working together every afternoon.
13. When you go out into the world, watch out for traffic,
hold hands and stick together.
14. Be aware of the power of two brains.
Upon collection of the quiz papers, the students were able
to ask questions about the experiment at this time. The subjects
were overwhelmingly positive about working collaboratively
in this course. The main question they had was if they were
going to be able to choose their own partners, or if I was
going to choose for them. At this time, the students were
given a Parental Permission form, a Consent Form (for those
students who were 18 years of age), and an Assent Form for
those students under the age of 18 (see Appendices C, D, and
E). All of these forms briefly explained the purpose of the
study and were to be returned to me the next day. The students
were also given a form on which they could list up to five
students with whom they would want to work collaboratively
with (Appendix H). This form also asked the students to name
up to two students whom they would not like to work with and
why. The results of this form remained anonymous. All of the
students chose to work with a close friend, and two students
chose to work with the same person. None of the forms listed
any students they would not like to work with. I chose to
let the students partner with their first choice, except in
the case of the duplicate request. I explained to the students
that these were their partners were for the entire year.
The other research questions were addressed by the use of:
• Electronic journals (blogs);
• Teacher observation;
• Questionnaires;
• Peer review surveys;
• Quiz and test scores.
Qualitative
Research Procedures
As their first journal assignment, the students were asked
to post their answers to the following questions on their
blogs:
1. Do you prefer working alone, or with someone? Why?
2. When you work with someone, do you prefer that your partner
be similar to you or vastly different from you? Why?
3. Do you think that you will be able to work faster with
a partner, or will the partner slow you down? Why?
4. Do you anticipate enjoying this pair-programming experience?
Why?
Six times during the semester, the participants were required
to give feedback in their blogs in which they will had to
answer specific questions about their collaborative experiences.
After each programming assignment, the students were asked
to individually submit answers to the following questions:
1. How much time did you spend on the assignment working alone?
2. How much time was spent on the assignment as a pair?
3. What is the level of confidence you have in your solution?
4. How much did you enjoy working on the assignment?
5. Did you enjoy the pair programming experience more than
working alone?
6. Do you think you did a better job with this problem because
you solved it in a pair?
7. Was there anything about the experience you particularly
liked?
8. Did you experience any particular frustrations with pair
programming?
9. Did you enjoy this experience more or less than your last
pair programming experience? Why, or why not?
I used observation techniques to determine whether or not
the students are on task during their pair programming time.
I observed whether the students were using correct
terminology when describing procedures to their partner. I
logged which pairings were off-task most often, and what they
are doing while they were off-task.
At the end of the experiment, the students completed a survey
providing advice to future collaborative programmers, as well
as provide feedback to me for future endeavors in utilizing
the pair programming model in A.P. Computer Science courses.
The students also stated whether or not they plan to pursue
a major/career in the computer science field.
Quantitative Research Methods
As an educator new to the implementation of the pair programming
model in a
high school, I was concerned that the academically weaker
or less motivated students would compel their partner to do
all the work. To possibly alleviate this concern, each time
the students had completed a programming assignment, they
were required to complete a peer evaluation on their partner.
The students rated their partner on a scale from 0 (poor)
to 20 (superior) for each of these five questions:
1. Did your partner read the lab assignment and preparatory
materials before
coming to class?
2. Did your partner do their fair share of the work?
3. Did your partner cooperatively follow the pair programming
model (rotating
the roles of driver and navigator)?
4. Did your partner make contributions to the completion of
the programming assignment?
5. Did your partner cooperate?
The sum of the ratings on each of these questions yielded
a grade from 0-100%. The peer rating factor counted as 5%
of the students’ programming grade. For example, if
a student received a 90% lab grade, and a peer evaluation
grade of 70%, he/she received a final lab grade of 88.5%.
Although the pair programming model stipulates that the students
work collaboratively on all aspects of the programming procedure,
all quizzes and tests were taken individually. These individual
quiz and test scores were used to analyze whether or not the
concepts were being effectively retained during this pair
programming experiment.
Confidentiality
To ensure the validity of the student responses on the student
questionnaires and blogs, participants were assured that all
of their responses would be kept confidential. They were also
assured that I, the researcher would be the only person privy
to their responses. I also told the students that their names
would be changed on the submitted version on this research
study.
Researcher Perspectives and Biases
I have taught at this high School since 1998. This is the
only school I have worked in. I worked in the private sector
for 10 years, was a stay-at-home mother for five years, and
then got my teaching certificate. I have a B.S. in Information
Systems Management from York College, a B.S. in Mathematics
from Georgia State University, and a M.S. in Mathematics Education
from Piedmont College. I am Gifted Certified in-field in Mathematics,
and I hold dual teaching certificates in Mathematics (7 -
12) and Business Education. My two passions have always been
mathematics and computer science, so I am honored to have
been asked to teach both subjects. There was not enough interest
in the Advanced Placement (A.P.) Computer Science course last
year, so it did not make. The Office of Curriculum and Planning
at this high School require at least 14 students register
for a course for it to make. There were only eight students
interested in taking A.P. Computer Science last year, so I
did not have the opportunity to teach the course the first
year the College Board changed the A.P. programming language
from C++ to Java. This was my first year teaching A.P. Computer
Science using the Java programming language. I taught A.P.
Computer Science in 2001 when the programming language tested
was C++.
I am a huge supporter of the use of collaborative activities
in the classroom. I often tell my students that I am a life-long
learner by the sheer nature of teaching. Reading all of the
research that Laurie Williams (Williams & Kessler, 2000)
has done on using the pair programming component to teach
introductory computer science courses in college has been
invaluable to me in my quest to promote the spirit of collaboration
in my classroom. Since Java is used to program applets for
use on the web as well as regular application programs, I
believe that using pair-programming would be a successful
endeavor. These students have an aptitude for problem-solving
and strong math skills already. My focus was to help them
learn how to effectively work with another person. I wanted
them to learn how to take and give constructive criticism.
I wanted to not just teach the material that would help the
students achieve a high score on the A.P. Computer Science
exam. I also wanted them to gain some experience with how
programming is done in many universities and software development
companies around the world.
Results and Discussion
Results
I used the following sources to obtain results for my study:
blog/journal responses, quiz scores, test scores, and observations
by me. To analyze the data from the observation log
that I kept, I first needed to focus in on exactly what I
wanted the students to be doing during their classtime. I
wanted them to fully take on the roles of driver and navigator,
as described by the pair-programming model. I wanted them
to reverse the roles when prompted to do so. I expected the
navigator to look for design flaws, typing/syntax errors,
logical errors, and develop algorithms and pseudocode when
necessary.
Based upon what I wanted the students to do during the pair-programming
exercises, I formed the following conclusions as evidenced
in the table below
(see Figure 4) The main initial concern that the students
had before the experiment officially began was that they don’t
typically like to work with another person. Overwhelmingly,
all of the students were concerned that their partner was
going to be slack in their share of the work. The majority
of the students thought that their partner would “slow
them down.” A little over half of the students said
that they would like to work with someone just like themselves.
When reviewing the responses after I’d gotten to know
the students, it was apparent that the high achieving students
wanted to pair with someone like themselves and the lazier
students preferred someone vastly different from themselves.
None of the students reacted negatively when I briefed them
on the process or asked if they had any questions, but their
blog responses were very different from the responses I got
in class. I think that nobody wanted to be the only one who
complained about the study, so they truthfully answered in
their blogs. So, the students were very skeptical about this
experiment, but willing to give it a valiant effort.
| Question |
Response |
| 1.
Do you prefer working alone, or with someone? Why? |
14/14
– I like to work alone.
Reasons
–
• I usually do all of the work in a group project
and the other person still gets the same credit as I
do.
• I don’t want to be responsible for someone
else’s grade.
• If my partner is absent, I can’t get my
work done.
• What happens if I get into a fight with my partner,
and we’re not on speaking terms?
|
2.
When you work with someone, do you prefer that your
partner be similar to you or vastly different from you?
Why?

|
8/14
– I prefer that my partner be similar to me.
6/14 – I prefer that my partner be vastly different
from me.
Reasons
–
• I am very hard-working and I would want my partner
to be hard-working as well.
• I’ve always been really smart and I don’t
have patience with dumb people.
• I usually don’t spend a lot of time on
schoolwork, so if my partner is lazy like me, we won’t
get anything done.
• I’m really good with computers, so I should
have no problem with this course if my partner is good
on the computers too.
• I don’t type fast, so I hope my partner
can type fast! I’m really good at finding other
people’s errors, though.
|
3.
Do you think that you will be able to work faster with
a partner, or will the partner slow you down? Why?

|
10/14
– A partner would slow me down.
4/14 – A partner would not slow me down.
• When I program, I usually just type in the first
thing that comes into my head, so if I have someone
looking over my shoulder, he’s going to break
my concentration.
• I don’t like to be constantly corrected
by another student. If it was the teacher, that would
be a different story.
• I think a partner would make me work faster
because I’d have the pressure of not holding him
up.
|
4.
Do you anticipate enjoying this pair-programming experience?
Why?

|
9/14 – I will enjoy this experience.
3/14 – I might enjoy this experience
2/14 – I will not enjoy this experience.
Reasons
–
• I will enjoy this class no matter how it’s
taught – I love computers!
• I will probably like this pair-programming thing
for a little while, but I might get sick of my partner
after a while.
• I won’t like working with anyone because
I think I’m the smartest one in here, and anyone
who I’m partnered with will hold me back.
|
With
less than a month remaining in the course, the students’
averages are summarized in the chart in Figure 5. These grades
do not include the 10 additional points given to Advanced
Placement students at the end of each semester. The student
with the failing average would still be failing with the 10
additional points added onto his grade.
Figure
5. Distribution of students’ grades.
The
students also completed a peer review survey on their partners
after each of the 6 major programming assignments that were
given. The peer review survey consists of 5 questions by which
the students rate their partner’s contribution(s) to
the project. The students would be rated on each question
on a scale of 0 (poor) to 20 (superior). This score would
count for 5% of the person’s programming grade. All
of the students gave their partner’s full credit for
every assignment, except for one student. The results of this
one student are shown below in Figure 6.
| |
Programming
Assignments |
| Questions |
1 |
2 |
3 |
4 |
5 |
6 |
Did
your partner read the lab assignment and preparatory materials
before coming to class?
|
15 |
10 |
20 |
17 |
20 |
20 |
| Did
your partner do their fair share of the work? |
10 |
5 |
10 |
10 |
10 |
10 |
Did
your partner cooperatively follow the pair programming
model (rotating the roles of driver and navigator)?
|
18 |
12 |
20 |
10 |
4 |
10 |
| Did
your partner make contributions to the completion of the
programming assignment? |
10 |
10 |
10 |
10 |
10 |
10 |
| Did
your partner cooperate? |
15 |
12 |
20 |
15 |
10 |
10 |
Figure
6 One student’s peer review survey results.
The quiz
and test averages for each of the students in this study are
shown below in Figure 7.
| Student |
Quiz
Average |
Test
Average |
| 1 |
93% |
89% |
| 2 |
83% |
78% |
| 3 |
55% |
45% |
| 4 |
75% |
78% |
| 5 |
96% |
90% |
| 6 |
91% |
84% |
| 7 |
87% |
88% |
| 8 |
98% |
96% |
| 9 |
72% |
79% |
| 10 |
86% |
88% |
| 11 |
91% |
90% |
| 12 |
70% |
80% |
| 13 |
95% |
94% |
| 14 |
82% |
80% |
Figure
7. Quiz and test results of students.
Conclusions
Research
Questions and Answers
This study was conducted in order to answer to answer the
following research questions:
1. Do the students enjoy working collaboratively on all of
the programming assignments in the A.P. Computer Science course?
2. As a result of using the pair programming model in the
A.P. Computer Science course, will the students have a higher
retention rate and perform with at least a “C”
average?
3. Will the students perform the roles of “driver”
and “navigator” as prescribed by the XP component
of pair programming effectively and without constant prompting?
In this chapter, I have listed the research questions along
with the evidence
obtained from the qualitative and quantitative data analyses.
From these analyses, I have drawn conclusions and discussed
the implications of these conclusions.
Do
the students enjoy working collaboratively on all of the programming
assignments in the A.P. Computer Science course?
The students did enjoy working collaboratively on all of the
programming assignments in the A.P. Computer Science course.
They worked harder to complete programming assignments because
of the shared pressure that resulted from the collaborative
partnerships. One of the students told me that he came to
school while he was ill, because he didn’t want to let
his partner down. Overall, the students seemed to be more
confident in their solutions because they had someone else
to validate their work before I even saw it. The students
enjoyed working in the pairings because it also gave them
the opportunity to talk to one another, instead of just sitting
there listening to a traditional lecture from me everyday.
The journal responses also indicate that when the students
employed the pair-programming model, it removed the taboo
of collaboration (cheating). My classroom was a very productive
and happy environment. Other teachers at the school often
commented to me that my A.P. Computer Science students would
always tell them that they really enjoyed the class. The students
would tell them how I let them work together on everything
except for quizzes and tests. I’ve even had a parent
communicate with me via email that his son really enjoyed
taking this course and having it delivered using this method.
The thinking of two bright minds and the steady dialogue between
the partners let me know that the students were indeed learning
through the experience of “teaching” their partners.
They understood that the idea was not to break the assignments
up into two pieces and integrate them later. They understood
that the idea was to work together as much as possible on
the program.
The students stated that they enjoyed the collaborative nature
of the course because they had someone to help them is they
were confused or unknowing. They had a friend to bounce ideas
off of. They also were more eager to attempt harder, more
challenging problems. I found that the students spent less
time doing debugging, since the debugging process was ongoing.
As a result of using the pair programming model in the
A.P. Computer Science course, will the students have a higher
retention rate and perform with at least a “C”
average?
All but one of the students involved in this study has at
least a “C” average, when the 10 additional points
are added onto their raw average grade. As a result of the
pair programming experience, the students had a high retention
rate because they were constantly quizzing each other. The
students involved in this experiment were very competitive
with each other, and with the other partnerships. They decided
on their own, that they would make flash cards to help them
with the vast vocabulary involved with this course. Before
we had a vocabulary quiz, the students would pull out their
flash cards and help each other with the terms and vocabulary.
The vocabulary quiz grades were excellent. Even the lowest
level student benefited from the camaraderie in the class.
The students not only memorized rote definitions, but were
able to give examples of terms and vocabulary.
Because the students were getting the material from me, the
textbooks, and their partners, they were able to grasp the
material better than if they only received it from one source.
In several blog responses, the students said that there were
times that their partner explained a concept to them that
they could not completely understand with my teachings.
Will
the students perform the roles of “driver” and
“navigator” as prescribed by the XP component
of pair programming effectively and without constant prompting?
Pair-programming – two programmers working side-by-side
at one computer collaborating on the same design, algorithm,
code or test – has been practiced in industry with great
success for years (Williams, Wiebe, Yang, Ferzli, & Miller,
2002). The role of the “driver’ involves the partner
who has control of the pencil/mouse/keyboard and is writing
the design or code. The other person, the “navigator”
continuously and actively observes the work of the driver
– watching for defects, thinking of alternatives, looking
up resources, and considering strategic implications of the
work at hand. The roles of driver and navigator are switched
between the pair periodically. Both are equal, active participants
in the process at all times and wholly share the ownership
of the entire program/project.
There were two groups of students that totally embraced the
pair-programming model whole-heartedly. These two pairs were
always on task, always active in their roles and always looking
for better ways to code/test/design. The dialogue between
these pairs was always positive, in terms of how they criticized
and/or complimented one another. Three of these four students
have the highest averages in the class at the time of this
writing.
The other 5 groups generally needed constant prodding to stay
on-task. Most of these students did not actively participate
in the role of navigator. If they weren’t the driver,
they lost interest and attempted to do other things –
surf the Web, do homework for other classes, check email accounts
– all of which are against class or school rules.
Part of the reason why the students did not embrace the “navigator”
role is that this was my first attempt at employing the pair-programming
model, and I was not able to facilitate their role as navigator
as well this first time through the experience. I didn’t
impose any consequences for the off-task behavior because
I wanted to get true data and I didn’t want the students
to become disenchanted with the experience. The other reason
the students didn’t embrace the navigator role is that
they are still high school students who don’t see the
importance of the more passive role. Perhaps with maturity
and time, they will understand how important this role really
is.
Recommendations
for Future Work
When I pursue the pair-programming model in future Advanced
Placement Computer Science classes, I would like to form the
partners with similar perceived technical skills. The groups
that worked the best together were composed of students with
similar perceived technical skills. There is existing research
that indicates that female students would benefit from working
in a collaborative setting. I would like to recruit more female
students and have them partner with each other. There is continued
under-representation of women in computer science and this
may be a strategy that would foster women’s interest
and promote their success.
The transition from working as a solitary programmer to pair-programming
took the students out of their comfort zone. It also took
me out of my comfort one as well. I had to deal with additional
issues such as one partner ending up with all the work, how
to distribute grades, etc. But, all-in-all, this experience
has been a positive one and I will continue to employ the
pair programming model well after the study is over.
References
American
Association of University Women Education Foundation (AAUW)
(2000). Tech-savvy educating girls in the new compute age
executive summary. Retrieved June 14, 2004, from http://www/aaiw/prg/2000/techsavvy.html
Beck, K. (2000). Extreme programming explained: embrace change.
Reading, MA: Addison-Wesley.
Bennedsen, J. (2001). Teaching Java programming to media students
with a liberal arts background. Retrieved June 8, 2004, from
University of Aarhus, Denmark, Department of Computer Science
Web site: http://www.ics.ltsn.ac.uk/pub/jicc7/bennedsen2.doc
Biggs, M. (2000). Pair programming: development times two.
InfoWorld, 22(30), 62-64.
Bishop-Clark, C., & Wheeler, D. (1994). The Myers-Briggs
personality type and its relationship to computer programming.
Journal of Research on Computing in Education, 26(3), 358-370.
Cockburn, A. & Williams, L. (2000). The costs and benefits
of pair programming. Retrieved June 8, 2004, from the North
Carolina State University Computer Science Department Web
site: http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.pdf
Davis, H. (2001). Managing diversity: experiences teaching
programming principles. Retrieved June 10, 2004, from University
of Southampton UK Department of Computer Science Web site:
http://www.ics.ltsn.ac.uk/pub/conf2001/papers/Davis.htm
Guzdial, M. (2000). Teaching the Nintendo generation to program.
Retrieved June 18, 2004, from Georgia Institute of Technology
College of Computing Web site: http://coweb.cc.gatech.edu/guzdial/uploads/17/CACM%5FNintendo%5F
Generation.pdf
Hill,
S. T. (2001). Science and engineering bachelor’s degrees
awarded to women increase overall, but decline in several
fields (National Science Foundation NSF 97-326). Arlington,
VA: National Science Foundation.
Katira, N., Williams, L., Wiebe, E, Miller, C. Balik, S.,
& Gehringer, E. (2004, March 7). On understanding compatibility
of student pair programmers. Paper presented at the 35th SIGCSE
Technical Symposium on Computer Science Education. Abstract
retrieved June 9, 2004, from http://db.grinnell.edu/sigsce/sigcse2004/viewAcceptedSession.asp?sessionType=Paper&sessionNumber=142
McDowell, C., Werner, L., Bullock, H., & Fernald, J. (2003).
The impact of pair programming on student performance, perception
and persistence. Retrieved June 9, 2004, from University of
California, Santa Cruz Computer Science Department Web site:
http://www.cse.ucse.edu/~charlie/pubs/icse2003.pdf
Murray, M. (2003, December 01). Math trial separates girls
from boys: Sagging scores prompt controversial approach. TheNewsJournal.
Retrieved June 11, 2004, from http://www.delawareonline.com/newsjournal/local/2003/12/01mathtrialsepara.
html
Nagappan, N., Williams, L., Weibe, E., Miller, C., Balik,
S., Ferzli, M., et al. (2003). Pair learning: with an eye
toward future success. Retrieved June 9, 2004 from North Carolina
State University Department of Computer Science Web site:
http://collaboration.csc.ncsu.edu/laurie/Papers/XPAUPairLearning.pdf
Thomas, L., Ratcliffe, M., & Robertson, A. (2003, February
19). Code warriors and code-a-phobes: a study in attitude
and pair programming. Paper presented at the 34th SIGCSE Technical
Symposium on Computer Science Education. Abstract retrieved
June 15, 2004, from http://gild.cs.uvic.ca/docs/psyc/codewarrior.pdf
Vygotsky, L.S., (1978), Mind in Society: the development of
higher psychological processes. Cambridge, MA: Harvard University
Press.
Williams, L. (1999, November 10). But, isn’t that cheating?
Paper presented at the 29th ASEE/IEEE Frontiers in Education
Conference. Abstract retrieved June 15, 2004, from http://collaboration.scs.ncsu.edu/laurie/Papers/Cheating.pdf
Williams, L., & Kessler, R. (2000) All I really need to
know about pair programming I learned in kindergarten. Communications
of the ACM, 43(5), 108-114.
Williams, L., & Kessler, R. (2001). Experimenting with
industry’s “pair-programming” model in the
computer science classroom. Computer Science Education, 11(1),
7-20.
Williams, L., Yang, K., Wiebe, E., Ferzlie, M., & Miller,
C. (2002). Pair programming in an introductory computer science
course: initial results and recommendations. Retrieved June
10, 2004 from North Carolina State University Department of
Computer Science Web site: http://collaboration.csc.ncsu.edu/laurie/Papers/EdSym_PL_0318.pdf
Williams, L., Wiebe, E., Yang, K., Ferzli, M., & Miller,
C. (2002). In support of pair programming in the introductory
computer science course. Computer Science Education, 12(3),
197-202.
Appendix
A
IRB
Approval Form
Appendix
B
County Public Schools Local School Research Request Form
Appendix
C
Parental
Permission Form
(to be completed either by the parents/legal guardians of
minor students)
I agree
to allow my child, ________________________________________,
to take part in a research study titled, “Experimenting
with the ‘Pair-Programming’ Model in the Advanced
Placement Computer Science Classroom”, which is being
conducted by Mrs. Michelle Venable-Foster, from the Instructional
Technology Department at the University of Georgia (770-736-4321)
under the direction of Dr. Janette Hill, Department of Instructional
Technology, University of Georgia, (706-542-4035). I do not
have to allow my child to be in this study if I do not want
to. My child can stop taking part at any time without giving
any reason, and without penalty. I can ask to have the information
related to my child returned to me, removed from the research
records, or destroyed.
The reason
for the study is to find out if having two students work collaboratively
at one computer to design all algorithms, codes, tests and
programs helps the quality of their programs and encourage
them to pursue computer science degrees in college.
•
The research is not expected to cause any harm or discomfort.
My child can quit at any time. My child’s grade will
not be affected if my child decides to stop taking part in
the research.
• The study will be conducted for 15 weeks during regularly
scheduled class. Throughout the duration of the study the
students will complete a web-based journal about their experiences
with the pair programming model, peer evaluation forms and
a survey at the end of the study.
• Any information collected about my child will be held
confidential unless otherwise required by law. My child’s
identity will be coded, and all data will be kept in a secured
location.
• The researcher will answer any questions about the
research, now or during the course of the project, and can
be reached by telephone at: (770) 736-4321, or by email at
Michelle_Venable_Foster@gwinnett.k12.ga.us. I may also contact
the professor supervising the research, Dr. Janette Hill,
Instructional Technology Department, at (706) 542-4035.
I understand the study procedures described above. My questions
have been answered to my satisfaction, and I agree to allow
my child to take part in this study. I have been given a copy
of this form to keep.
__I DO
give permission to you to reproduce materials that my child
may produce as part of classroom activities. No last names
will appear on any materials submitted by the teacher.
__I DO
NOT give permission to reproduce materials that my child may
produce as part of classroom activities.
_________________________
_______________________ __________
Name of Researcher Signature Date
Telephone: ________________
Email: ____________________________
_________________________
_______________________ __________
Name of Parent or Guardian Signature Date
Please
sign both copies, keep one and return one to the researcher.
Additional
questions or problems regarding your child’s rights
as a research participant should be addressed to Chris A.
Joseph, Ph.D. Human Subjects Office, University of Georgia,
612 Boyd Graduate Studies Research Center, Athens, Georgia
30602-7411; Telephone (706) 542-3199; E-Mail Address IRB@uga.edu
Appendix
D
Consent
Form
I, ________________________________________,
agree to take part in a research study titled, “Experimenting
with the ‘Pair-Programming’ Model in the Advanced
Placement Computer Science Classroom”, which is being
conducted by Mrs. Michelle Venable-Foster, from the Instructional
Technology Department at the University of Georgia (770-736-4321)
under the direction of Dr. Janette Hill, Department of Instructional
Technology, University of Georgia, (706-542-4035). I do not
have to be in this study if I do not want to. I can stop taking
part at any time without giving any reason, and without penalty.
I can ask to have the information related to my work returned
to me, removed from the research records, or destroyed.
The reason
for the study is to find out if having two students work collaboratively
at one computer to design all algorithms, codes, tests and
programs helps the quality of their programs and encourage
them to pursue computer science degrees in college.
•
The research is not expected to cause any harm or discomfort.
I can quit at any time. My grade will not be affected if my
child decides to stop taking part in the research.
• The study will be conducted for 15 weeks during regularly
scheduled class. Throughout the duration of the study you
will complete a web-based journal about your experiences with
the pair programming model, peer evaluation forms and a survey
at the end of the study.
• Any information collected about me will be held confidential
unless otherwise required by law. My identity will be coded,
and all data will be kept in a secured location.
• The researcher will answer any questions about the
research, now or during the course of the project, and can
be reached by telephone or by email. I may also contact
the professor supervising the research, Dr. Janette Hill,
Instructional Technology Department, at (706) 542-4035.
I understand the study procedures described above. My questions
have been answered to my satisfaction, and I agree to take
part in this study. I have been given a copy of this form
to keep.
__I DO
give permission to you to reproduce materials that I may produce
as part of classroom activities. No last names will appear
on any materials submitted by the teacher.
__I DO
NOT give permission to reproduce materials that I may produce
as part of classroom activities.
_________________________
_______________________ __________
Name of Researcher Signature Date
Telephone: ________________
Email: ____________________________
_________________________
_______________________ __________
Name of Participant Signature Date
Please
sign both copies, keep one and return one to the researcher.
Appendix
E
DATE__________________________
Minor
Assent Form
Dear
Student,
You are
invited to participate in my research project titled, “Experimenting
with the Pair-Programming Model in the Advanced Placement
Computer Science Classroom.” Through this project I
am learning about how students learn programming in collaborative
pairs.
If you
decide to be part of this, you will allow me to pair you up
with a partner with whom you will work with on all of your
programming assignments. You will allow me to watch you and
take notes while you are coding, testing, and writing programs.
Your participation in this project will not affect your grades
in school. I will not use your name on any papers that I write
about this project. However, because of your participation
you may improve your problem solving techniques. I hope to
learn something about pair programming and its benefits to
learning computer science.
If you
want to stop participating in this project, you are free to
do so at any time. You can also choose not to answer questions
that you don't want to answer.
If you
have any questions or concerns you can always ask me or call
my teacher, Dr. Janette Hill at the following number: 706-542-3810.
Sincerely,
Michelle Venable-Foster
Instructional Technology
University of Georgia
604 Aderhold Hall
Athens, GA 30602
I understand
the project described above. My questions have been answered
and I agree to participate in this project. I have received
a copy of this form.
___________________________________ __________________
Signature of the Participant Date
Please
sign both copies, keep one and return one to the researcher.
For additional questions or problems about your rights as
a research participant please call or write: Chris A. Joseph,
Ph.D., Human Subjects Office, University of Georgia, 606A
Boyd Graduate Studies Research Center, Athens, GA 30602-7411;
Telephone (706) 542-3199; E-mail Address: IRB@uga.edu
Appendix
F
Screenshots
of Student Websites

APPENDIX
G
Peer Programming
Observation Log
Date: August 9, 2004 Time: 8:30 – 9:28
Observations: Shane and Dane are working well. They are alternating
appropriately and the “navigator” is finding a
lot of errors in the “drivers” work. Jake and
Donna have been told twice already to stay on task and not
surf the internet. The navigator is not doing his/her job.
The students seem very excited about being on the computers,
but not about doing the assignment. R.J. has completely dominated
the assignment and his partner, Don is doing his math homework.
When I told him to take on the role of navigator, he told
me that J.R. already knew what he was doing and didn’t
need his help. I announced that they should switch, and Don
didn’t know what had been typed in, and had no idea
about where to go from there. Leo keeps trying to play a game
on the internet. Seat changes will be made tomorrow.
Date:
August 10, 2004 Time: 9:00 – 9:28
Observations:
Late start today – fire drill. They are very anxious
to get on the computer and “play.” They seem to
be more on task after the seats have been changed. J.R. is
determined to be the first one done so he can surf the internet.
Don is still not being observant. It seems like the driver
is the only one making the decisions. I announce that I’m
watching them and grading them for class participation. Now
the students are making a valiant attempt to take on the proper
roles. I was impressed that most of the navigators in the
pairs were using correct terminology when suggesting corrections
to the drivers. Shane K. told Leo that he should his file
name should be the same as the class name. Shane L. asked
Dane to consider a different algorithm to make the robot move.
I heard the following vocabulary words used:
Class
Method
Algorithm
Compiler
Statement
Block
Date:
August 17, 2004 Time: 8:30 – 9:28
Observations: Eleven of the students have already changed
their robot graphics! Dane has changed his robot to resemble
The Grim Reaper. Leo has changed his to resemble a rock star.
They are really responding very well to the immediacy of JKarel
the Robot. If the robot moves the right way – they know
that their code is correct. They told me that they appreciate
that I’ve put all of the required software on a disk
for each of them. Eight of them said that they’ve loaded
the software on their home computers. One student Instant
Messaged (IM) me last night around 8:00 to ask about installation.
Apparently, he didn’t download the proper JDK before
he attempted to install BlueJ – the Java IDE. We basically
just talked today and didn’t do any work on the computer.
Date:
August 18, 2004 Time: 8:30 – 9:28
Observations: The assignments are getting more time intensive
and require work to be done out of the classroom. I suggested
that the students communicate via email or IM with their partners
outside of class. They all said that this would not be a problem.
Jake is trying to go to a discussion board instead of working
on his assignment. I had to go over and close out his browser.
He didn’t say anything about it. I’ve had to reiterate
that the navigator should not be on a computer. I told them
that only one monitor should be on per pair of students. Braden
and Erik are working very well today. Terms heard today:
Logic error
Compilation error
Lexical error
Parameter
It sounds
like they’re learning the terminology.
Date:
August 30, 2004 Time: 8:30 – 9:28
Observations: It is very apparent who the dominant students
are, and which ones are passive. There are two groups where
both of the students are dominant, but they work well together.
They seem to be so competitive with each other, so they make
it a game to try and find errors in the other ones code. It
seems to make them try harder to code correctly. One student
told me that he was feeling ill and was going to check out
after this class. He said that the only reason he came in
at all was because he didn’t want to let his partner
down. Apparently, he had the code saved in his directory –
not the shared drive, and if he didn’t come in, his
partner would not have been able to get any work done on it.
Some of the groups are trying to rush through the assignment
so they can surf the net. I told them that when they finish,
they had to log off of the computers.
Date: September 9, 2004 Time: 8:30 – 9:28
Observations: Two pairs have really bought into the pair programming
philosophy and have met at each other’s homes to work
on their projects. I can tell by the efficiency of the algorithms
that they are taking their time with the programs. Shane L.
has written a program to make JKarel add binary numbers! He
asked if he could show the class. So, he used the SmartBoard
and demonstrated his program. The other kids were very impressed.
Don is not paying attention again. I’m not sure he understands
the discipline required for this course. When Shane L. finished
his presentation, the other students talked about writing
programs to make JKarel do other “tricks.”
Date:
September 10, 2004 Time: 8:30 – 9:28
Observations: The students came right in and got into their
pairs and began working, even before the bell rang today.
Branden came to me earlier today and asked how long he had
to keep the same partner. I told him that I was planning to
have the students keep the same partners for the entire semester.
He told me that he wasn’t comfortable with his current
partner. He didn’t want to say anything bad about Eric,
but I could tell he was unhappy. After much prodding, he told
me that Erik has a hygiene problem, and he really didn’t
like working that physically close to him. He wants me to
switch him to partner with R.J. I had already known about
Erik’s hygiene problem, but I think part of the reason
that Braden wants to switch is because he was the only student
who didn’t get his first choice in partner selection,
and R.J. is probably the highest achiever in the class right
now. I told him that I would take his request under advisement
and let him know after the weekend. Right now the students
are working on developing an algorithm to have JKarel harvest
a field of corn. Since they weren’t allowed to turn
on their computers until after I checked their pseudocode,
I had the opportunity to overhear a lot of dialogue about
how the program should be designed and implemented. Shane
L. and Dane were finished first and had a very good design.
They always want to go beyond the requirements of the assignments.
They spend the most time out of class time working on Java.
Date:
October 4, 2004 Time: 8:30 – 9:28
Observations: We are giving JKarel a break right now to learn
some Java basics. Although I told the students that they did
not have to work in pairs for this week, they asked if they
could anyway! They had already sat next to their partners
(even Braden and Erik). They were very attentive today as
I taught in a more traditional way than I had been doing.
When Keith asked a question about iterations, before I could
answer him – Peta answered him. Peta apologized for
interrupting, but I told him it was fine, since he explained
it so well and used the correct terminology. Keith is very
dependent on Peta, and looks lost when Peta has not been there.
He told me that he’d rather ask Peta questions that
to ask me, because he doesn’t want to look stupid in
front of everyone in the class. I assured him that his questions
are probably the same questions the others are afraid to ask.
I enjoyed hearing the students associate everything I was
teaching to JKarel. They made wonderful connections and were
able to see the symmetry between robotics and coding. Eleven
of the students began working on the homework as soon as I
assigned it. The other three students tried to get on the
computers and just play around. I told them to log off if
they didn’t want to begin their homework.
Date:
October 5, 2004 Time: 8:30 – 9:28
Observations: Before I went over the homework assignment from
last night, I told the students to get with their partners
and compare answers. Jake and Donna had not done their homework,
so they attempted to work through as much as they could before
I either went over it or collected it. Don hadn’t done
his homework either, so their “compare” time was
spent with R.J. trying to explain the assignment to him. Don
said, “I need to start doing the work for this class.”
R.J. asked him why he registered for the course if he didn’t
want to do the work, and Don said that he didn’t know
it was going to be so much work. He said that he didn’t
know that it involved so much math and written assignments.
Don said that he was going to read the book over the weekend.
R.J. told him that it would be easier if he would read it
as it was assigned. Shane L. and Dane compared their homework
and had one discrepancy. They called me over to ask which
one had the correct answer. I told them to run through the
code and figure out which answer was correct. They simulated
a run, without the computer, and found that Shane L. was correct.
Dane found out that he was running through a “while”
loop incorrectly. I gave out colored pencils and asked them
to make any corrections they had with the colored pencils
so when I collected it, I could decide which concepts needed
more emphasis, based on the corrections made. The students
who didn’t do any of their homework were upset because
all of their assignment would be in the colored pencil and
I would know that they hadn’t done their homework!
Date:
October 14, 2004 Time: 8:30 – 9:28
Observations: Students were given the “Quadratics”
and “Taxes” program to work on and were asked
to flowchart the program first. Most of them wanted to either
use the Drawing Tools in Word or in Powerpoint to design their
flowchart. Three of the students didn’t know that these
software packages had flowchart symbols in them, so this was
a great discovery for them. They worked cohesively on designing
the flowcharts. Two groups (Shane L. & Dane, and Leo &
Shane K.) actually designed pseudocode together on paper before
they decided on creating the flowchart. They all agreed that
the flowchart would help them write the code. They still are
antsy when I ask them to do work that involves paper instead
of the computer. Mike even wants to take his notes on the
computer. Since his attention span is not up to par –
I usually don’t allow him to do this. After about 2
minutes of pouting, he took out some paper and started the
assignment. There was good conversation about the shapes of
the proper flowchart symbols and transforming pseudocode to
Java code.
Date:
October 15, 2004 Time: 8:30 – 9:28
Observations: I gave the students the option of working independently
or with their partners. R.J. usually does all of the work
by himself anyway, so I wasn’t surprised when he said
that he would work alone. His partner, Don, looked lost as
he tried to do his work alone. It is apparent that he was
totally dependent on R.J. and had no clue on what we were
doing. I watched as he started BlueJ and typed in the first
two lines of code and just stopped. Eventually, he moved over
to R.J.’s computer and started asking him questions
about how to code the program. R.J. asked him how far he’d
gotten and Don told him he hadn’t made any progress
at all. R.J. scolded him about not doing his fair share of
the work thus far, but he did eventually help him out a bit.
Jake and Donna attempted to log onto a discussion board instead
of doing their work. They kept trying to minimize the browser
window when I walked by them. I took them into my office and
explained to them that they were in violation of the Acceptable
Use Policy of the school when they logged onto an authorized
website. They could be disciplined up to loss of computer
usage at the school up through the end of the year and would
fail the course by default. They apologized and said that
they wouldn’t do it again.
Date:
November 3, 2004 Time: 8:30 – 9:28
Observations: We went through the Advanced Placement Computer
Science test curriculum on the College Board website today.
Dane asked me if they could take the A.P. exam in pairs! He
said that he and Shane L. are such a good team because they
complement each other in terms of their strengths and weaknesses.
They said that between them, they could get every question
right on the exam! I told them that although they would encounter
collaborative opportunities many times in their lives –
it usually won’t be during a testing situation. The
class also wanted me to ask some of their other teachers to
employ pairing in their classes! I told them that it was appropriate
for many disciplines and gets rid of the “sharing is
cheating” aspect, but it takes special planning and
facilitation is a lot harder than one would imagine. They
said that they could see themselves working with the “right”
partner in a teaming situation on a job.
APPENDIX
H
Peer Programming
Partnership Request
Name:
__________________________________
I would
like to be partnered with: (list up to 5 people)
1. _________________
why? _______________________________________
2. _________________ why? _______________________________________
3. _________________ why? _______________________________________
4. _________________ why? _______________________________________
5. _________________ why? _______________________________________
I would
not like to work with: (list up to two people)
1. _________________
why? _______________________________________
2. _________________ why? _______________________________________
APPENDIX
I
Peer Evaluation Form
Your
name _______________________________________
Partner’s name ____________________________________
Assignment ______________________________________
Please answer the following questions using a scale of 0 (poor)
to 20 (superior) for each. This score will count as 5% of
your partner’s programming grade.
Question Score
1. Did your partner read the lab assignment and preparatory
materials before coming to class?
2. Did your partner do their fair share of the work?
3. Did your partner cooperatively follow the pair programming
model (rotating roles of driver and navigator)?
4. Did your partner make contributions to the completion of
the programming assignment?
5. Did your partner cooperate?
Total
Additional
Comments: