Pair Programming

1
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
  williams_at_csc.ncsu.edu

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
• Maslows 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 dont check e-mail
  messages or favorite Web pages they dont 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
Maslows 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 others judgment
  and each others 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