An Evaluation of Pair Programming Practice


Published on

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

Published in: Education, Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

An Evaluation of Pair Programming Practice

  1. 1. An Evaluation of Pair Programming
  2. 2. Contents •Introduction •Characteristics •Variants of Pair Programming •Strengths and Weaknesses •Defect Prevention by Pair Programming •Resistance to Pair Programming •Related Metrics •Conclusion
  3. 3. 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
  4. 4. 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
  5. 5. 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).
  6. 6. 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.
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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