1. Present by Monvorath Phongpaibul “Molly”
Pair Programming
Present by
Monvorath Phongpaibul
“Molly”

2. Out line: Pair Programming Presentation
Overview
Related Work
CSP
Qualitative Results
Quantitative Results

3. Overview

4. Overview
“Two programmers working side-by-side, collaborating on the same design, algorithm, code or test. One programmer, the driver, has control of the keyboard/mouse and actively implements the program. The other programmer, the observer, continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects and also thinks strategically about the direction of the work. On demand, the two programmers can brainstorm any challenging problem. Because the two programmers periodically switch roles, they work together as equals to develop software” by -- Laurie Williams North Carolina State University Computer Science

5. Related Work

6. Related Work
PSP (Personal Software Process)
Distributed Cognition

7. PSP (Personal Software Process)

8. PSP (Personal Software Process)
By Watts S. Humphrey of Software Engineering Institute (SEI)
Defines a software development framework: operations/sub-process, measurement and analysis techniques
Purpose : Understand own skills in order to improve their own personal performance
Composed of scripts and templates/ forms fill in

9. PSP Philosophies
The longer a software defect remains in a product, the more costly it is to detect and remove it
Defect prevention is more efficient than defect removal
The best estimates, and therefore the best commitments, for schedule and defect rates can be made with a historical database of information
CSP (Collaborative Software Process) is an extension of the PSP, and it relies upon the foundation of the PSP

10. Distributed Cognition
Mick Flor (1991)

11. Distributed Cognition
The sharing of goals and plans:
Goals specify what needs to be done
Plans specify the means by which the goals are achieved
Efficient Communication: The current state of the problem combined with the programmers’ shared goals and plan are sufficient to determine the intent of most utterances
Searching through larger spaces of alternatives:
The actors bring different prior experiences to the task
The actors may have different access to task relevant information
The actors stand in different relationships to the problem by virtue of their functional roles
Shared memory for old plans:

12. CSP (Collaborative Software Process)

13. CSP (Collaborative Software Process)
Level CSP
0.0 Baseline/Current Process Baseline
0.1 Coding Standard
Size Measurement
Process Improvement Plan
1.0 Analysis (Use Case) Quality Management
CRC Card Design Brainstorming
Design
1.1 Code Review
Design Reviews
Testing
Measurements
2.0 Size Estimation Project Management
Resource Estimating
2.1 Task Planning
Schedule Planning

14. Qualitative Results

15. Qualitative Results
Summer 1999: pilot experiment with 20 undergraduate students in a web programming class
Fall 1999: official experiment with 41 juniors and seniors students

16. Qualitative Results (cont.)
Why Pair Programming is beneficial
Pair-Pressure
Pair-Think
Pair-Relaying
Pair-Reviews
Debugging by Explaining
Pair-Learning
Team Building
Project Risk
Maslow’s Needs Hierarchy

17. Qualitative Results (cont.)
Success Factors for Effective Collaboration
Pair-Jelling
Project Ownership
Mutual-Respect and Self-Respect
Ego-Less Programming
Workspace Layout
Taking Breaks

18. Why Pair Programming is beneficial?

19. Pair-Pressure
The programmers admit to working harder and smarter on programs because they do not want to let their partner down
“Two people working together in a pair treat their shared time as more valuable. They tend to cut phone calls short; they don’t check messages or favorite Web pages; they don’t waste each others time”
All assignments on time and average grade was 98%

20. Pair-Thinking
“We often came up with different ideas about how the design should go and the result of arguing over which one was better often led to a truly superior hybrid design”

21. Pair-Relaying
“One problem with single programming is that you can forget….

22. Pair-Reviews
The earlier a defect is found in a product, the cheaper it is to fix the defect.
“Four eyeballs are better than two”

23. Debugging by Explaining
“When I explained an idea to my partner, I concentrated on what I was saying, and carefully made things clear and logical because I did not want to confuse my partner and I wanted him to understand what I was talking about. It helped me better understand the problem I was addressing. It also helped me discover some mistakes I had made but did not notice before I talked with my partner.”

24. Pair-Learning
The continuous reviews of collaborative programming create a unique educational capability, where by the pairs are endlessly learning from each other
“The process of analyzing and critiquing software artifacts produced by others is a potent method for learning about languages, application domains, and so forth”

25. Team Building
“A baseball manager recognizes a nonphysical talent, hustle, as an essential gift of great players and great teams. It is the characteristic of running faster than necessary, moving sooner than necessary, trying harder than necessary. It is essential for great programming teams too. Hustle provides the cushion, the reserve capacity, that enables a team to cope with routine mishaps, to anticipate and forefend minor calamities.”

26. Project Risk
“How many of few people would have to be hit by a truck before the project is incapacitated?”
Ans: “ONE”
With Pair Programming, the risk from losing key programmers is reduced.

27. Maslow’s Needs Hierarchy
Self Actualization Needs
Esteem Needs
Belongingness and Love Needs
Safety, Security Needs
Physiological Needs (Food, Water)

28. Success Factors for Effective Collaboration

29. Pair-Jelling
“A jelled team is a group of people so strongly knit that the whole is greater than the sum of the parts. The production of such a team is greater than that of the same people working in unjelled form. Just as important, the enjoyment that people derive from their work is greater than what you'd expect given the nature of the work itself. In some cases, jelled teams working on assignments that others would declare downright dull have a simply marvelous time. … Once a team begins to jell, the probability of success goes up dramatically. The team can become almost unstoppable, a juggernaut for success”

30. Pair Ownership
“With pair programming, the two programmers become one. There should be no competition between the two; both must work for a singular purpose, as if the artifact was produced by a singular good mind. Blame for problems or defects should never be placed on either partner. The pair needs to trust each other’s judgment and each other’s loyalty to the team”

31. Mutual-Respect and Self-Respect
“And indeed, there can be no doubt of von Neumann's genius. His very ability to realize his human limitation put him head and shoulders above the average programmer today Average people can be trained to accept their humanity -- their inability to function like a machine -- and to value it and work with others so as to keep it under the kind of control needed if programming is to be successful.”

32. Ego-Less Programming
“Ego-less programming,” an idea surfaced by Gerald Weinberg in The Psychology of Computer Programming a quarter of a century ago, is essential for effective pair programming. According to the pair programming survey, excess ego can manifest itself in two ways, both damaging the collaborative relationship. First, having a “my way or the highway” attitude can prevent the programmer from considering others ideas. Secondly, excess ego can cause a programmer to be defensive when receiving criticism or to view this criticism as mistrust.

33. Workspace Layout

34. Taking Breaks
Have some break: disconnect from the task and refresh

35. Quantitative Results

36. The Experience Report from PP

37. Quantitative Results An Economic Evaluation of the Pair Programming
Pair Quality
Pair Time
Net Present Value Analysis
Engineer Satisfaction
Pair Satisfaction
Pair Confidence

38. An Economic Evaluation of the Pair Programming

39. Pair Quality
Postdevelopment Test Cases Passed

40. Pair Time
Elapsed Time

41. Net Present Value Analysis
Cost Savings Of CSP Through Time

42. Engineer Satisfaction

43. Pair Satisfaction

44. Pair Confidence