THE CONCEPTS OF HEARTWARE IN COLLABORATIVE LEARNING FOR PROGRAMMING

1. THE CONCEPTS OF HEARTWARE IN COLLABORATIVE LEARNING FOR PROGRAMMING Mohamad Fauzan Noordin (PhD)Roslina Othman (PhD)Faculty of ICTInternational Islamic University Malaysia

2. 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

3. 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.

4. 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. 5 critical attributes to successful collaborative learning approaches common task small group learning cooperative behavior positive interdependence individual accountability (Davidson, 1994; Preston, 2005)

6. 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

7. Concepts of Heartware • Part of Peopleware • Comprises • emotional quotient (EQ) and • spiritual quotient (SP) • Leads to human behavior, attitude, judgment, and decision making.

8. IT Components and Heartware • IT components : • Peopleware • Hardware • Software • Heartware

9. Attributes of Heartware Positive interdependence, Understanding the user needs, Compassion on the task, Positive attitude and good understanding Teamwork.

10. Computer: Peopleware, Hardware, Software…Heartware Peopleware Heartware Hardware Software

11. Merciful + Heartware Journey of Peopleware Adapted from: Thompson, 2001

12. Research Objective: • To examine the adoption of heartware concepts in collaborative learning in relation to PAIR programming

13. Reported issues Heartware issues Level of tolerance in team-learning through trial and error Controlling tempers due to long hours of waking side-by-side ~refresh and rest. Deals with personal issues by themselves Not to remember who write which line of code~ code resulted from the synergy of experience and skills. ~ solving in their (each) own way Acknowledging emotions ~accept that people are different; ~response to emotional situations (e.g. style flex) Establishing trust through helping each other (Weinberg and House , 1985) (Bolton, 1996)

14. 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/

15. 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/pair-programming-etiquette/

16. 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/

17. 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‘tmake 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/

18. 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/

19. 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/

20. 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/

21. Pairing Different Categories of Programmer Expert-expert Expert-average Expert-novice Novice-novice (Stephens and Rosenberg, 2011)

22. "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 full-flow. (Stephens and Rosenberg, 2011)

23. 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)

24. 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)

25. 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)

26. Our Experience: • Our Grading Scale • 95 – 100% = A+ • 90 – 94% = A • 85 – 89% = B+ • 80 – 84% = B • 75 – 79% = C+ • 70 – 74% = C • 65 – 69% = D+ • 60 – 64% = D • Below 60% = F • Establishment stage • 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%) • At this phase: • Collaborative learning at learning sessions • All assessments – individual marks • In the Future: • Collaborative learning at the assessment level

27. 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

28. 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

29. 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

30. 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

31. 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