Skip to content

Pair programming

Learning objectives

  • Understand why pair programming is important
  • Understand what good pair programming looks like
  • Practice pair programming
  • Practice to convert class diagrams to real code
For teachers

Prerequisites are:

  • Learners can do the git basic workflow on main

Teaching goals are:

  • Learners can tell why pair programming is important
  • Learners can tell how good pair programming looks like
  • Learners have practiced pair programming
  • Learners have converted class diagrams to real code

Preparation:

  • A shared document where duos can assign themselves to a class, needed for exercise 2
  • The learner project must have a folder /src/[package_name] where learners can put their code, needed for exercise 2

Lesson plans:

gantt
  title Lesson plan pair programming 1
  dateFormat X
  axisFormat %s
  Introduction : intro, 0, 5s
  Theory 1: theory_1, after intro, 5s
  Exercise 1: crit, exercise_1, after theory_1, 15s
  Feedback 1: feedback_1, after exercise_1, 5s
  Theory 2: theory_2, after feedback_1, 5s
  Exercise 2: crit, exercise_2, after theory_2, 10s
  Exercise 2 after the break: crit, after exercise_2, 5s
gantt
  title Lesson plan pair programming 2
  dateFormat X
  axisFormat %s
  Exercise 2: crit, exercise_2, 0, 5s
  Feedback 2: feedback_2, after exercise_2, 10s
  Theory 3: theory_3, after feedback_2, 5s
  Exercise 3: crit, exercise_3, after theory_3, 10s
  Feedback 3: feedback_3, after exercise_3, 5s
  Start TDD: done, extra, after feedback_3, 45

Introduction

Pair programming is a facet of developing code better. We use it a lot in this course, because:

  • it is recommended by influential software development classics [Martin, 2011][Thomas & Hunt, 2019]
  • scientific evidence is mixed, however, e.g.
    • a pair considers more alternative ways for a solution [Flor et al., 1991], however, this is only 2 programming teams
    • 96% of developers prefer pair programming over developing alone [Williams & Kessler, 2000], however, this is only 41 respondents
  • what is for sure: it works great with recommended teaching practices, e.g. grouping up learners is effective [Hattie, 2012][Schwartz & Gurung, 2012, page 65] (with the optimal group size of 2 [reference for best group size 2]) and indeed the Programming Formalisms learners like it as they write in the retrospective

Exercises

Exercise 1: understand pair programming

Learning objectives
  • Understand what pair programming is
  • First guess at understanding what good pair programming is
  • Together, read the questions before reading the material
  • Together, divide which team member is going to read which source:
  • Together, set a timer for 10 minutes
  • Individually, answer the questions within the time limit
  • Together, write down a shared answer on the GitHub project repository with path learners/[a teammember's name]/pair_programming.md
  • Upload the file to the GitHub repo. Use the GitHub web interface if pushing is a problem!

Questions:

  • What is pair programming?
  • How does a good pair behave? Describe what can be observed when pairing online
  • When to switch roles? Give a procedure
  • What effects does pair programming have?
Answers
  • What is pair programming?

Pair programming is a software development practice in which two developers work on the same computer. The person with the keyboard ('the driver') develops new code. The person without the keyboard ('the navigator') reviews the code.

  • How does a good pair behave? Describe what can be observed when pairing online

In an online course:

  • A good pair has the driver sharing his/her screen
  • In a good pair, both people talk a lot
  • A good pair switches roles regularly
  • A good pair has a lot of commits
  • When to switch roles? Give a procedure

Any procedure to achieve the goal of regularly switching roles:

  • after enough work has been done to put in a git commit such as 'Add documentation', 'Add test', 'Pass test'
  • each time a timer goes off, e.g. after 5 minutes

The first procedure sometimes fails when a driver (thinks he/she) has much more knowledge than the navigator on the subject and is (apparently) inexperienced in good pair programming. In such cases, the second procedure work better.

  • What effects does pair programming have?

All material for this exercise show references to studies that show advantages of pair programming, for example (from two Wikipedia references):

  • a pair considers more alternative ways for a solution [Flor et al., 1991]
  • 96% of developers prefer pair programming over developing alone [Williams & Kessler, 2000]

However, the first study uses only 2 programming teams, the second study 41 self-selected respondents. One can/should be critical on these studies.

Yet, for teaching, working is groups has a high effect size [Hattie, 2012], where the optimal group size is two [Schwartz & Gurung, 2012].

Exercise 2: practice pair programming

Learning objectives
  • Practice pair programming
  • Practice to convert class diagrams to real code

Before doing the exercises:

  • Reach an agreement on how to do pair programming: among others, decide upon the first driver and when to switch roles.

The exercise, to be done as a pair:

  • In the course's shared document, there is a list of classes extracted from the design document. Assign yourselves to write a class together
  • Find the GitHub repository of a Programming Formalism student project done in an earlier cohort. Find where the Python code for classes ended up. Look for the Python code of the most simple class.
  • Write the minimal code of your class together. Share code by pushing it to the main branch. 'Minimal code' means only the name of the class, without any behavior!

Reflect:

  • Were roles swapped often enough?
  • Did you solve unexpected problems well?
  • Did the driver always share his/her screen?
  • Did each team member contribute?
  • Did each team member contribute to the code in the Python class?
Answers to what needs to be done

The hardest part will be to understand how little needs to be done here.

A file needs to be created at src/bacsim/[class_name].py. For example, for a coordinate, this file will be called src/bacsim/coordinate.py

The contents of the file is -maybe unexpectedly- minimal. Here I show a good example from an earlier Programming Formalisms cohort:

"""A coordinate somewhere in space."""

class Coordinate:

    """Where am I?."""
Answers to reflection
  • Were roles swapped often enough?

Ideally, each learner was the driver at least twice. However, the task may have been finished before that happened and if that is the case, that is OK.

  • Did you solve unexpected problems well?

One can expected some unexpected problems. It can be that one person struggled with git and he/she should have been given the proper time to fix this and work on the problem.

  • Did the driver always share his/her screen?

Sure, one can stop sharing when opening an email client for a GitHub message :-)

  • Did each team member contribute?

This does not need to be code!

  • Did each team member contribute to the code in the Python class?

With this problem, maybe not everyone in the duo wrote the one line of actual code. This is OK.

Exercise 3: practice pair programming again

Learning objectives
  • Practice pair programming
  • Practice to convert class diagrams to real code
  • Do the previous exercise for another class, including the reflection

Reflect additionally:

  • As a pair, how did you improve?
  • As a pair, how could you have done better?
  • As an individual, how could you have done better?

References

  • [Flor et al., 1991] Flor, Nick V.; Hutchins, Edwin L. (1991). "Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance". In Koenemann-Belliveau, Jürgen; Moher, Thomas G.; Robertson, Scott P. (eds.). Empirical Studies of Programmers: Fourth Workshop. Ablex. pp. 36–64. ISBN 978-0-89391-856-9.
  • Fowler's website
  • [Hattie, 2012] Hattie, John. Visible learning for teachers: Maximizing impact on learning. Routledge, 2012. TODO: check that this is a reference for optimal group size of 2

  • [Martin, 2011] Martin, Robert C. The clean coder: a code of conduct for professional programmers. Pearson Education, 2011.
  • [reference for best group size 2] The reference that a group size of 2 is best
  • [Schwartz & Gurung, 2012] Schwartz, Beth M., and Regan AR Gurung. Evidence-based teaching for higher education. American Psychological Association, 2012. TODO: check that this is a reference for optimal group size of 2

  • [Thomas & Hunt, 2019] Thomas, David, and Andrew Hunt. The Pragmatic Programmer: your journey to mastery. Addison-Wesley Professional, 2019.
  • [Williams & Kessler, 2000] Williams, Laurie; Kessler, Robert R.; Cunningham, Ward; Jeffries, Ron (2000). "Strengthening the case for pair programming" (PDF). IEEE Software. 17 (4): 19–25. CiteSeerX 10.1.1.33.5248. doi:10.1109/52.854064.