An Evaluation of Pair Programming Practice
Upcoming SlideShare
Loading in...5
×
 

An Evaluation of Pair Programming Practice

on

  • 249 views

A short evaluation of the Pair Programming practice, from an academic perspective.

A short evaluation of the Pair Programming practice, from an academic perspective.

Statistics

Views

Total Views
249
Views on SlideShare
249
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

An Evaluation of Pair Programming Practice An Evaluation of Pair Programming Practice Presentation Transcript

  • An Evaluation of Pair Programming
  • Contents •Introduction •Characteristics •Variants of Pair Programming •Strengths and Weaknesses •Defect Prevention by Pair Programming •Resistance to Pair Programming •Related Metrics •Conclusion
  • Pair Programming •An eXtreme Programming practice •Software development technique •A defect prevention method •Involves two programmers working side-by-side on a common task •P1: Driver •P2: Navigator or Observer •They switch roles periodically
  • Characteristics •Two programmers •Pressure of work is divided between two programmers. •Partners help each other to concentrate on work. •Partners brainstorm and distribute cognition while working •Continuous reviews contribute better defect prevention •Improves quality with minimum budget and resources
  • Variants of Pair Programming Remote pair programming •Also known as distributed pair programming or virtual pair programming •Two programmers situated at different locations team up as a pair to work on same code and design using common shared text editors and collaboration tools Ping Pong pair programming •Programmer 1: Writes a failing unit test (Ping) •Programmer 2: Makes a test pass by writing necessary implementation code (Pong) •Programmer 2: Writes a new failing unit test (Ping) •Programmer 1: Makes a test pass by writing necessary implementation code (Pong) •Go back to Step 1 (Follow this iteration for all pairing session).
  • Variants of Pair Programming (Contd.) Cross Functional pair programming (CFPP) •It addresses development of embedded systems. •CFPP pair consists of a software engineer working together with a hardware engineer to create a module or an entire embedded system. •CFPP usually involves programming, debugging, simulations, emulations, etc.
  • Strengths of Pair Programming •"Two persons can think more than one" •It reduces risk of Repetitive Stress Injury (RSI) •It helps in improving learning capabilities •Knowledge passes easily between pair programmers. •Decreased risk to management •Improved quality •Reduced cost of development
  • Weaknesses of Pair Programming •Some programmers may prefer to work alone •A programmer might get intimidated by other •Personal conflicts •Annoying personal habits •Decisions like "Whom to pair?" is difficult to decide
  • Defect Prevention •Pair Programming prevents code and design defects •It is a type of continuous reviewing of work •Continuous reviews help in defect prevention and defect removal
  • Resistance to Pair Programming •Lack of familiarity and knowledge over the technique •People are unwilling to take up the new idea of pairing seriously because many are accustomed to traditional solo programming •Many consider pairing as a waste of time, money, and resources because the team requires time to learn •It takes time to convince management •No time for pair programming due to deadline pressure
  • Related Metrics Productivity of a Single Person Number of Lines of Code produced by a single programmer during one month period Pair Speed Advantage Ratio between time required by a single programmer and time required by pair programmers for performing some task Defect Density The average number of defects per a unit of LOC. Pair Defect Advantage Ratio between defect density of pair programming and defect density of traditional software development Product Size Number of Lines of Code or Function Points
  • Conclusion •Pair programming is not applicable to every software project •Success of pair programming depends on coordination and cooperation between the partners •Bad pairing may result in lower productivity and quality •Do not use pair programming while working on complex problems •We suggest using pair programming - WHEN - oTask complexity is low and schedule pressure is high oTask complexity is high and schedule pressure is low