Ideas on Pairprogramming

10-06-2014 by Sebastian Schürmann

Over the last years, I got many good Ideas from teams on how to use pairing in their daily work. It is very interesting how the initial idea is “hacked”, changed and adapted. Some traditional and not so traditional approaches here in a blog post.

Pair “Promiscuously”

Everyone pairs with everybody else is a nice way to get knowhow shared in your team. Sometimes it is a hard start, but when you have completed this for the first time, there will be foundations of teamwork that are hard to achieve otherwise. Some of the advantages of doing so.

  • Learn to know development setups of your colleagues
  • Understand the reasoning behind that ‘quirky’ behavior everyone shows once in a while
  • This is a good team building exercise
  • You will probably lift the level of the person who is ‘the weakest link’ in your teams ‘chain’
  • This is the number one way to reduce the bus factor

Pair and change on Red-Green-Refactor

You can pair in a environment with Unit-Tests and make a change not based on time (although it is good to set a maximum time limit) but when you go forward in the re-green-refactor loop. Use the following Cycle when starting with a green lit unit test suite:

  • Person A: Add a test that makes the suite go: red
  • Person B: Implement code so that it goes to: green
  • Person A: Refactor (all still green)
  • Person B: Add a test that makes the suite go red:

Remark Always on green tests and rector make a commit. Push to master if you are done

This is very good to learn and internalize the way TDD in its purest form as in test first works. It will give you very good insight in the method and produce code. You can have a very fast cycle here as soon as the basics between the two persons pairing are sorted out.

Pair Red-(Green-Refactor)

This is a variant of the above, but with the exception that one person makes the tests green and refactors them. This is a little more training oriented and can be used to teach a newbie essential skills in software development and TDD.

Hint Even if it is hard for you as the expert: The newbie should write the code. Doing creates a way better understanding.

Pair with the new person on the team

Speaking of newbies how about this: The next time you onboard a new team member you do not make his setup for the development environment for a week. Instead you let him pair with every member of your team for a longer time.

New colleagues in a company are still free from most of the organizational duty and are often stuck in a situation where they have to ask a lot of questions in order to be productive. Codebases are big and the details of implementations are specific: The new person will have a hard time to contribute to productive code and learn at once. By pairing with a experienced team member this problem can be solved. You do not even need a computer and this can be done from the moment a new person enters the office.

Remark This leads to a extremely lowered on boarding time. Additionally the person can actively bring his skills to the table.

Pair a Release

Releases kinda suck. Always a bit. A little more when you do not have a complete Integration and Continuous Delivery pipeline set up and there is stuff to be made by “hand”. Often this “duty” will be on one person and thereby you create a single point of failure in many ways. It is hard to review a release. You just know if it worked or not. So working as a pair might be a good thing. Shitty duty gets more fun this way and the peer-pressure will keep the pair in line not to cross the many lines in a release process that can be harmful just for sloppiness. Releases suck. Been there done that.

Pair a Bugfix

Bug fixing kinda sucks too. At first something is not working. After it you will be looking for the source of the bug and then you will find out that you have made a very specific mistake (you as in team). This burden can be shared. It’s not that your colleagues have not made the same kind of errors (or worse) in the past. We are humans. So lets get this painful duty over with as a pair. The bugfixes will be more complete (because they are challenged by your navigator) and there will be less problem with regressions. Additionally: Two people learn at once what mistake not to make next time and two people can bring their knowhow to the table regarding this specific problem. It’s making a fail a win-win (as far as possible).

Pair writing a User-Story

Writinglearning a User-story is often done by the product owner. And when the teams first re-views the story, a lot of technical remarks and constraints are added etc. In this situation, the product owner often resembles just to “write these informations down” and is not learning too much. Why? The amount of information that a team of developers generate in a grooming or estimation meeting is just to high in that moment very often. Change this a bit: Stay with the grooming meeting but let the product owner write down the User story together with one of the developers. Just use driver and navigator as in normal pairing and a blank text file. The story will be more dense of information and the additions that have to be made by the whole team a little less.

Pair a spike

Coding experimental features to prove that something works is called a spike in XP. Another name for that is a “Research Task”. This is one of the cooler thing and might be very good to do it as a pair. Why?

  • It’s mainly a learning opportunity. Learning is important.
  • I see that a wide range of knowledge is required for most of these. So two persons knowledge might help to make a successful spike happen (or just successfully find out it is not working how you anticipated).
  • more than one person will have the freedom to work on a new thing. It is just motivating to “move fast and break stuff”.

It would be nice to get some other ideas from you here in the comments section. What is your special way of Pairprogramming?

Upcoming Workshops

Pairprogramming Workshop

comments powered by Disqus