THE CONCEPTS OF
HEARTWARE IN
COLLABORATIVE
LEARNING FOR
PROGRAMMING
Mohamad Fauzan Noordin (PhD)
Roslina Othman (PhD)
Faculty of ICT
International Islamic University
Malaysia
Collaborative Learning and
Programming
• “Collaboration between programmers on the same
design, algorithm, code and test” (Wiebe et al, 2003)
• Collaborative learning has been proven to be
effective in improving and retaining students in
programming courses (e.g. Bevan et al, 2002 and
McDowell, 2002)
• Learners regarded collaborative learning to be
effective, motivating and enjoying and have
confidence in programming
 Educational benefits:
~increased satisfaction
~reduced frustration
~increased confidence
Heartware and Programming
• Programming (Pair Programming involves )
 Navigator – Driver relationship and role, possibly
two switch roles
• Brainstorming on a strategic plan
• Negotiating course of action
• Monitoring tactical and strategic defects
(navigator)
• Explaining what was done and seeking advice
(driver)
 Requires a balanced partnership, continuously,
rigorously, affectively, efficiently, and patiently
 Thus Heartware strengthen this bonding.
Heartware and Collaborative
Learning (CL)
• Involvement of human-to-human
interaction
Emotional state that color the human
impression
Spiritual state that picture the human
perception
Thus, heartware comes into the
scene.
5 critical attributes to successful
collaborative learning approaches
1. common task
2. small group learning
3. cooperative behavior
4. positive interdependence
5. individual accountability
(Davidson, 1994; Preston, 2005)
Pair programming explained
• Pair programming is not one person passively watching
the other type.
• Each programmer needs to play an active role in
determining the design, implementation and tests.
• The pair works together on the task in hand while passing
keyboard control back and forth between them, writing
code and tests as they go.
http://accu.org/index.php/journals/1395 Pair Programing Explained
Concepts of Heartware
• Part of Peopleware
• Comprises
emotional quotient (EQ) and
spiritual quotient (SP)
• Leads to human behavior,
attitude, judgment, and decision
making.
IT Components and Heartware
•IT components :
 Peopleware
 Hardware
 Software
 Heartware
Attributes of Heartware
• Positive interdependence,
• Understanding the user needs,
• Compassion on the task,
• Positive attitude and good understanding
• Teamwork.
Computer:
Peopleware, Hardware,
Software…Heartware
Peopleware
Heartware
Hardware
Software
Merciful +
Journey of
Peopleware
Adapted from: Thompson, 2001
Heartware
Research Objective:
• To examine the adoption of heartware
concepts in collaborative learning in relation
to PAIR programming
Reported issues Heartware issues
1. Level of tolerance in team-learning through
trial and error
2. Controlling tempers due to long hours of
waking side-by-side
~refresh and rest.
3. Deals with personal issues by themselves
4. Not to remember who write which line of code~
code resulted from the synergy of experience
and skills.
~ solving in their (each) own way
5. Acknowledging emotions
~accept that people are different;
~response to emotional situations (e.g. style flex)
6. Establishing trust through helping each other
(Weinberg and House , 1985) (Bolton, 1996)
Programming Etiquette as Part
of Heartware Concepts
Navigator:
• Wait until the test is passing to nitpick on coding standards.
• Ask nicely for the keyboard to “show” what you mean.
• After “showing” what you mean, offer the keyboard back.
• If they don’t take your advice, let them finish doing the task their way and
then show them after they’re done.
• It is good to inform the driver of keyboard shortcuts and refactorings but
don’t interrupt the programming flow too much with advice that is not directly
related to the programming task.
Driver:
• Don’t ignore or get frustrated when your pair tells you a better way to do
something.
• Auto-format so your navigator can read your code easier.
• Don’t be stubborn about giving up the keyboard when your navigator seems
to know what they’re talking about.
• If the navigator is confused by what you’re doing, talk them through it by
having a whiteboard conversation.
Source:
http://javidjamae.com/2006/12/15/pair-programming-etiquette/
Style 1: The Commander and The
Grunt, or The Backseat Driver
• Driver is a junior, or new to the project, language, domain
• Navigator is well informed and probably be faster if he
didn't’t have to wait for the driver to do what he is told.
• The grunt is clearly in the way of the commander:
 The irritation as the commander gives more low level
instructions:
• “Extract field. NO don’t type it, press Ctrl-Alt-F! No not there,
select the method invocation first, no no no, you don’t need to
select every letter, did you use this IDE before? Give me the
keyboard and I’ll do it.”
Source:
http://javidjamae.com/2006/12/15/pairprogramming-etiquette/
Style 2: The Rally
• This is the style that preempted the driver and
navigator metaphor.
 In a rally both the driver and the navigator have
been where they are before, they know each other
very well and they need only a small word to
communicate.
• In a rally car you will hear things like: “Hard right. 3″
“All out” “Left 6″.
 If the navigator forgets an instruction the driver
will just do the right thing anyway, and the
navigator will continue with the next one.
 There is room for error, the chance of a crash is
severely reduced by having the navigator there.
Source:
http://javidjamae.com/2006/12/15/pair-programming-etiquette/
Style 2: The Rally..continue
As a driver you should:
• Think out loud: “When I solve this with A now I won’t have to refactor B before I
can see if it works” “I’m running the test before fixing the properties file, we can
do that later”
• Voice your expectations: “This test is going to pass now” “This should give me
three invocations on this mock because I’ve simplified x”
• Ask the obvious: “What’s next, ah yes we still need to fix that properties file”
“Can we commit like this?”
• Give a heads up: “When we have done this we’ll see some trouble in module A,
we need to fix that too”. And then trust your navigator to worry about it while
you get there as fast as you can.
As a navigator you should:
• Follow the storyline and stop the driver if it doesn‘t make sense
• Actively confirm or reject assumptions
• Ask for arguments if a driver takes a non obvious solution: “Why are you doing
that, if we change this property it already works, right?”
• Look for the nearest exit: “If you fix that test now we can do a commit first, the
build will be green”
• Think ahead. If the driver gives you a heads up, he might not see a dead end.
Think it through for a few seconds and then tell him if you don’t think you’re
heading to a solution.
• Find a way out before you get blocked. This is the hardest one. Even if you’re
not sure you’re running into a dead end it’s good to keep an eye out for
alternative routes to an exit. This will save time when you need to back out of
something.
Source:
http://javidjamae.com/2006/12/15/pair-programming-etiquette/
Style 3: The Tour
• When a navigator looses focus and the
driver is basically showing him around.
Still you can switch back into rally style,
but requires a little effort on both sides.
• Start touring and stick to the best
behavior given in Style 2: The Rally
• If doesn’t happen within less than ten
minutes, switch pairs.
Source:
http://javidjamae.com/2006/12/15/pair-programming-etiquette/
Style 4: The Disconnected Pair or The
Sleeping Navigator
•
Start off as discussing the design, walking through the code,
and when the driver is on his way, the navigator shuts down his
brain. The driver knows what he’s doing and because the
navigator doesn't pick up on what he’s saying he turns silent
and speeds up. The navigator sees that the driver is doing ok
and decides not to slow him down but space out and look out
the window a bit.
•
As a driver you can suddenly revert all your changes and see if
the navigator notices.
•
As the navigator you can stand up and walk away to get a
coffee. Just acknowledge that you have disconnected and
something needs to change.
•
Those are the four main styles of pairing I’ve seen employed
and I’ve tried all of them extensively, both in collocated and
distributed teams. Before I will go into some things that are
more important in distributed pairing I will get back to the point
of pairing being tiring. Pairing is more tiring because you work
harder.
Source:
http://javidjamae.com/2006/12/15/pair-programming-etiquette/
Style 4: The Disconnected Pair or The
Sleeping Navigator …continue
The problem is that it is hard to remember that your brain needs a
lot of stuff to do its job. In order of importance they are:
• a small break at least once every 45 minutes (every 20 minutes is
better)
• water (most headaches are caused by dehydration)
• glucose (eat fat or proteins which are much more effective than raw
sugar, but you need to eat them longer in advance)
• a good nights sleep
• caffeine (coffee really works and I hear it’s healthy too)
• The problem with pairing is that people (especially developers) like
to pretend that they are machines and don’t need to have a break.
A good navigator will ask for a break after each commit and make
sure there is a commit each half hour. If you’re collocated you can
even talk about how things are going, how far away from a commit
you are etc at the coffee machine, where you also take a glass of
water and a sandwich if you feel like it. You should also remember
that most people can sustain hard brain work for at most 6 hours of
the day, you can crank this up by doing sports and a healthy diet, but
it’s normal to be out of it after 8 hours. Just go home…
Source:
http://javidjamae.com/2006/12/15/pair-programming-etiquette/
Pairing Different Categories of
Programmer
• Expert-expert
• Expert-average
• Expert-novice
• Novice-novice
(Stephens and Rosenberg, 2011)
"Go Make Me a Cup of Tea" Syndrome
(Expert-Novice)
• To "get the easier job done well, while training a
novice programmer." The challenge the expert must
take on a tutoring role and must maintain extreme
patience throughout. If the expert coder slips, then
the result is a "watch while I type" session,
• The novice remains passive throughout and the
expert is effectively solo-coding.
• Distinct advantages to expert-novice pairing. In fact,
it’s probably the one pairing combination that’s
worth mandating, as long as the novice is willing and
able to learn and the expert is prepared to give up a
portion of her day to teach rather than code in fullflow.
(Stephens and Rosenberg, 2011)
Laurel and Hardy Take Up Pair
Programming (Novice-Novice)
• "To produce production code in a relatively
noncomplex area of the project, giving valuable
experience to both programmers in the process.”
• Determine which part of the project is unimportant
enough that you can afford to unleash two complete
novices, unsupervised, on it. produce code that isn’t
exactly production quality.
• There must be a coach, instructor, or mentor available
to answer questions and also to help guide the pair,
there’s a risk that the coach may become fully
occupied with mentoring one particular pair anytime
two novices pair up.
(Stephens and Rosenberg, 2011)
Carrying Your Pair – (Expert-Average)
• The average programmer truly is average (i.e., the
average programmer is likely to stay that way and will
never really progress).
• The average programmer doesn‘t interact enough
with the expert.
• The average programmer doesn't seem to "get it" and
keeps asking the same question over and over:
• "This can leave the expert frustrated and can reduce
the ability of the pair to complete the task.”
(Stephens and Rosenberg, 2011)
And the Winner Is . . . (Expert-Expert)
•
Aside from the longer-term learning benefits, it seems that the
most beneficial form of pairing is with two programmers of
roughly the same level of expertise. It’s more likely that the pair
will be on the same wavelength and will spend less time
disagreeing over things that probably don’t matter that much.
Design Documents Reduce Reliance on Pair Programming
•
Design documents provide a record of design decisions. This
makes them particularly helpful for novice programmers to
explore the thinking behind the design, as described by the
more experienced senior programmers. If the team is becoming
lost in a sea of changed minds and refactoring, the design
document often helps to remind the team members of why they
originally decided to do something in a particular way. There’s
usually a pretty good reason.
•
Problem: Over confidence
(Stephens and Rosenberg, 2011)
Our Experience:
• Establishment stage
Our Grading Scale
• Course: Programming Language 1
 Introductory level
• English language proficiency
 Switching medium of instruction
 Average and below
• Sessions:
 Theoretical (2 hrs/week)
 Practical/hands-on (2 hrs/week)
• Assessment:
 2 Midterms (20%)
 2 Lab Quizzes (10%)
 Participation (10%)
 Final Lab Test (20%)
 Final Examination (40%)
•
•
•
•
•
•
•
•
•
95 – 100%
90 – 94%
85 – 89%
80 – 84%
75 – 79%
70 – 74%
65 – 69%
60 – 64%
Below 60%
= A+
=A
= B+
=B
= C+
=C
= D+
=D
=F
At this phase:
•
•
Collaborative learning at learning
sessions
All assessments – individual marks
In the Future:
•
Collaborative learning at the
assessment level
Learning and Learners:
• Textbook and Lab Manual
 Algorithm and code side-by-side
• 2 groups:
 Collaborative learning (n=55%)
• PAIR Programming
 Non-collaborative learning (n=45%)
• Solo programming
• Seeking advice only (from the tutor) or senior
students
Collaborative Learning:
• Steps:
 They chose their own partner
 Assess their ability before teaching the course
• 1st assignment (graded participation)
• Mostly novice-novice
 Assign tutor as the expert
• Giving advice
• No switching of role with the tutor
 Assign role – navigator for algorithm and
driver for coding
•
•
•
•
Switching when driver needs help
When moving to the next task
In class/lab plus outside of class
Tasks: programming exercises
Our Implemented Heartware Elements:
• At this phase:
 Emotional quotient
• Take time to be aware of feelings e.g. anger,
frustration
• Breathing exercise
• Assess your partner
• Tolerance and be polite
• Punctuality
• Professional friendship (e.g. give-and-take, open,
rational, fair, kind)
 Spiritual quotient
•
•
•
•
Take a break (afternoon prayer)
Exchange of remembrance
Evaluate one’s own belief
God-Man and Man-Man relationships
Results:
•
Collaborative learning (PAIR Programming)
 Scored on (Bloom’s Taxonomy):
• Remembering and understanding levels
– No significant difference with non-collaborative learning group
• Applying and Analyzing levels
– Significant difference with non-collaborative learning group
• Evaluation and Creating levels
– Significant difference with non-collaborative learning group
• Observations and Remarks:
–
–
–
–
•
Less dependency on the Tutor
Quick response in class and less repetition in lab
Shows confidence before and after examination and tests
At first perceived programming as one program requires one brain only;
else crashed
Non-collaborative learning (Solo Programming)
 Scored on (Bloom’s Taxonomy):
• Remembering and understanding levels
– No significant difference with non-collaborative learning group
• Applying and Analyzing levels
– Average grade: C
• Evaluation and Creating levels
– Average grade: D
• Observations and Remarks:
– Frustration with (Un-helpful) Tutor
– Time consuming
– Shows inferiority complex
Conclusion:
• Heartware concepts to fit into the PAIR programming
 Tutoring by expert
 Tracking the works
 Guided role
• Emotional quotient
• Spiritual quotient
• Attributes of Heartware
 Positive interdependence
 Understanding your partner
 Compassion on the task
 Positive attitude
 Teamwork