What do you do if you want to have a reliable system? You make sure you have redundancy: More than one component can do a certain job. You back up you valuable data to a separate system. You have two servers to provide your critical service, in case on fails. Yet, many projects have no plan for the inevitable absence of people with critical knowledge.
We practice pair programming to get redundancy. This manifests itself in many ways:
- When someone is sick, on vacation or leaves the project (to become a doctor, say), the project doesn’t suffer. Or rather, it doesn’t suffer as much. We do get less work done if fewer people are present, of course. And many of our developers have areas where everyone loves to get their help.
- We can add new people to the team. Learning how the system works is just a matter of pair programming as part of the normal rotation.
- We are very adaptive to varying focus at different times in the project. If we had someone who could only work with, say, databases, he wouldn’t have much to do at some times, and too much to do at other times. With pair programming, we still have people who’re especially good in some areas, but everyone can help out with whatever needs doing.
- No parts of the code are off-limits. As every commit of the code is written by two people, no one person has the right to block changes to “his” code. Anyone can make the changes that they need to complete their current task as good as they can.
- The team is working with fewer tasks at a time. As teams grow in size, there can be a lot of different things happening at the same time. This both increases the chances that people will step on each other’s toes (that is, work on the same source code files) and increases the amount of “Work in progress” at any one time. Pair programming effectively halves the amount of work in progress.
- Everyone has a understanding of the whole system. During planning and design discussions, everyone can contribute. Instead of focusing on technical components and subsystems, the discussion is about how to solve the user story as a whole.
Some studies focuses on the impact of pair programming on efficiency, quality, progress, or even focus. I think it’s much more interesting to see how pair programming changes the dynamic of the team. From a group of individuals, we form teams where everyone is appreciated as a contributor. Everyone has their individual strengths, but more importantly, everyone has the same goal in mind: The success of the team.
When I started pair programming daily, it changed my life and my projects for the better. I often point to pair programming as one of the most influential possible interventions on any projects. Very often, an audience member with a healthy degree skepticism will inquire about the research into pair programming.
Sadly, the practice of software engineering research has not come very far in this area, so the questioner is left unsatisfied. In this blogpost, I will summarize the current state of research into pair programming, and describe my hopes for the future.
Pair programming and test-driven development are some of the practices that are most often talked about and least often actually understood. So I’ve decided to undertake the task to teach myself to program a simple, yet realistic problem with a pair programming partner. The goal is to create an entertaining and realistic performance that portrays what it feels like to work like this.
I’ve been extremely lucky. I’ve found not one, but two programmers that have been willing to train enough with me to make a smooth performance of a pair programming session. The result is the Java EE Spike Kata. My colleagues in Steria, Anders Karlsen and Ivar Nilsen have been great to work with. Between us, we’ve showed the kata at three conferences, and more are coming.
Here is the performance at JavaZone 2010 by Anders Karlsen and myself.
The Java EE Spike Kata from JavaZone on Vimeo.
Make sure to watch the video in full screen mode as there will be LOTS of code.
Some things to watch for when you’re watching a (paired) code kata:
- How are we working together? How often are we changing who’s at the keyboard? What will the person who’s not at the keyboard be doing?
- How do we progress from one test to the next? When do we decide to modify an existing test and when do we decide to add a new one? How much of the test do we write before we start modifying the production code?
- How are we writing the production code? How often are we refactoring existing code?
- How are we using the IDE? What tricks do we use to take advantage of the code completion facilities? How often do we use the mouse and how often do we use the keyboard?
I also hope to be putting up the video of me and Ivar Nilsen at the TelecomCity conference in Sweden. As we’d both practiced even more for that performance, I think it’s even smoother than the JavaZone performance.
(Kudos to Cisco Norway, formerly Tandberg, for excellent filming services at JavaZone. And thank you to Robert “Uncle Bob” Martin for turning me on to code katas in the first place)
As it turns out, one of the least used practices of agile development is also one of the most powerful.
Up into the start of last year, I only worked sporadically with pair programming. Last year, I was lucky enough to be part of a team that used pair programming all the time. Since I’ve experienced real pair programming, I never want to give it up.
Pair programming offers benefits to many stakeholders:
- As a developer, you will have more fun at work. You will get to know your colleagues better and experience flow practically the whole day. You will be tired by the end of the day, but you will also feel like you’ve accomplished good work.
- The team will have a higher quality code base that everyone is comfortable with.
- As an architect or team lead, you will have a good way to contribute even if you only have a little time before a meeting. You will also have a better chance to influence the rest of the team, instead of just issuing edicts that nobody follows.
- As the project manager, you will have a more flexible team. If someone gets sick, goes on vacation or moves to another project, there won’t be a big problem.
- As the customer, you will get better quality code faster.
With these benefits in mind, why doesn’t everybody pair program? Well, it is unfamiliar, a little scary, and exhausting when you start out. Most developers are not used to having other watch them code. Or to focus on the task at hand the whole day.
Here are some techniques I’ve seen have effect for teams transitioning to pair programming:
- Code dojos: Everyone on the team gets together and programs a sample program or a spike together. Two people sit at the keyboard, while the rest watch on a projector. Rotate pairs frequently. This lets everyone get comfortable with coding as a social activity.
- Pair programming should be the norm, but allow for exceptions. If people only pair program occasionally, they end up not pair programming at all. If people are forced to pair program when they just need some time by themselves to think, they will not be happy pair programming.
- The pair programming star: Write the names of the team members in a circle. Every time two people pair program, draw a line between their names. Keep the pair programming star in a visible location.
- Facilities: The furniture can make it harder to get started pair programming. Consider using two mice, two keyboards and perhaps two monitors per PC to make it easier. Or use VNC for desktop sharing.
- Give it time: Pair programming is exhausting when you first start doing it. It will take a while before people are comfortable with the new pace. But once they switch, they will never want to go back.
For more inspiration, see these presentations from the Smidig 2009 conference (in Norwegian):
Lately, I’ve been working on two code katas, that is, programming exercises that I repeat until the motions are secure in my muscle memory. The katas I’ve chosen are:
- Java EE Spike: An application that stores People with names to a database and lets me search for them. I’ve repeated this pair programming with several different programmers.
- Programmable Fizz Buzz: Create a sequence of numbers 1,2,fizz,4,buzz,fizz,… you know the one. And the twist: Make it programmable, so that for example numbers divisible by 7 should be replaced with “coconut”.
I’ve learned a lot from repeating these exercises:
- Using test-driven development it takes me longer to get to something that “should work in principle”, but shorter to get to something that works correctly.
- When refactoring to a new data structure, add the new structure while keeping the old one, make switching between them as simple as changing a single line. Delete the old when it works.
- There’s always an automated refactoring you still want to help you out. Extract Parameter Object was my big one.
- Writing for example a method invocation and then using quickfix to have the IDE generate the method is the quickest way of writing code available to you.
- After 8 iterations, the Java EE Spike takes me 80 minutes solo. Pair programming with another programmer who had practiced: 65 minutes. I don’t know why!
- Pair programming a moderately complex kata like the Java EE Spike is fun. It’s also a good chance to discuss different roles of different tests.
- There is a huge difference between a test that takes 3 seconds to run and one that takes 0.5 seconds when you’re test driving. More surprisingly, there’s a big difference between a test that takes 0.5 seconds and one that takes 0.01 seconds
- If you think test-driven development is not for you or that it’s bunk, you probably write really slow tests.
What are your latest coding observations?
The last couple of months have been full speed and not much time to reflect and write. The fact that we’re pair programming on the team gives me less time to think about great blog subjects.
As an architect, it’s hard to find enough time to complete a meaningful unit of work without doing the dreaded “architect-commit-and-run” move. However, I found that when I have time to program, the pair programming culture on our team works really well. Even though the whole team is very excited about pair programming, there’s usually someone who’s not paired up when I get back from a meeting or finish some paperwork. Pairing up with someone is a great way to get some meaningful work completed in the middle of a day full of interruptions.
The team I’m on now is also remarkably good with pair programming, so it’s always fun. For most of the time, pair programming has been the default, but I ended up occasionally working solo for a few days in a row every now and then. Then, I was unable to pair for a few days. I found myself more easy distracted, more nervous about the quality of my work, and at the end of the day, more exhausted. Two of my team mates reported similar experience.
I think an instrumental part of the success of pair programming on this team was both to apply a little bit of force in making sure that people switched pairs daily for a while and the fact that team allowed the more skeptical members to pair programming less. In the end, everyone prefers pairing for almost all their work. After our last retrospective, we’ve instituted a pair programming star: An area on our whiteboard where the names of the team members are listed in a circle. Every time two people pair up, we draw a line between their names. Sadly, as I’m knee deep in analyzing the next release, my name doesn’t have many lines going to it.
But I hope that will change. Pair programming should be instrumental to the daily work of any architect.
People always talk about how learning is something that happens in groups. Last week, I got reminded of the point as a task I had previously struggled with alone became trivial in a pair programming episode.
The first time I tried coding “a bowling scoring program” was in 2001. I’ve practices the exercise many times later. In 2004, I tried to write a more challenging version: Write a program that prints the numbers that should be displayed on a score board for a partially played game of bowling. I got bogged down and sidetracked, and didn’t come up with a very good solution at all.
Last week, my company invited Ron Jeffries and Chet Hendrickson to give a short course in pair programming and test-driven development for 15 of our developers/testers. Ron and Chet has coded this particular program a number of times, but never with the score board variation I mentioned.
In the second half of the course, I sat down with two others of our developers who had never worked on this exercise before. We quickly finished the simple game, and then someone proposed the score board. I said “oh, that’s way too hard, we’ll never finish it in time for the course”.
To make a long story short: I was wrong. Together, we solved the problem in no time flat.