For the last few months I had opportunity to practice Pair Programming and observe other people using it. I’ve made observations, analysis and reasoning what can we expect from this technique and how to perform it to be successful. This post is a result of that research.
What is more, this is a summary of my speech “Pragmatic Pair Programming”. It was already performed at Java Developer Days, Kraków 2014 (http://14.jdd.org.pl/) and Spread IT, Gliwice 2014 (http://spreadit.pl/) conferences.
Mentioned talks materials (in polish) can be found at:
- Slides: http://krzysztofszabelski.com/talks/pair-programming-pragmatycznie
- Video should be available soon at http://14.jdd.org.pl/
Pair Programming is one of the Extreme Programming practises. It helps us to achieve teams’ goal of delivering useful and working software on time, through supporting multiple partial goals:
- Classical Pair Programming lets us to produce better quality software, which reduces costs of further development and maintenance. In this technique one person writes code, while the other analyses the current solution, looking for better one and considers further steps.
- Using Pair Programming as Mentoring tool lets us to leverage team’s competencies and to reduce risk of hidden technical defects, as well as to improve performance in a longer perspective.
- Both of the above techniques help to prevent or get rid of knowledge silos, which is situation when only a limited number of team members is able to work on particular part of software. It is a huge risk of hidden problems in such code areas or delays because it is a bottleneck and a single point of failure.
Introducing Pair Programming isn’t easy due to social and psychological reasons. Also, it is easy to not to get expected results, without understanding why pair programming should work.
Where Pair Programming came from
Pair Programming is one of Extreme Programming (XP) practices. This methodology was formalized by Kent Back in “Extreme Programming Explained: Embrace Change” book in 1999 and clarified 5 years later in its second edition. The book is the result of intense discussions about good software practices on world’s first wiki and Kent’s experiments with those practices in C3 project in Chrysler Corporation.
In short, XP is based on best software development practices taken to extreme level. In this context, observation, that code reviews are beneficial, leads XP practitioners to conclusion that they should review code instantly, so they will be programming in pairs.
Why Pair Programming should work
Our brain is composed of two hemispheres. Scientific research proves that they are responsible for different things. Left hemisphere takes care of sequences and logical tasks processing. Regarding software development, they are responsible for e.g. writing code, structuring conditional statements, or procedural programming on the low level of abstraction. Whereas, the right one handles abstract thinking, holistic view on a problem, intuition. Therefore, something that we need to model good solution, consider all the use cases and properly balance our time between different aspects of the created solution. In other worlds, it is necessary for us to think about the software at a higher level of abstraction.
It is easy to notice that in order to effectively solve a nontrivial problem with the help of software we need to use both hemispheres. The issue is that they have problems with synchronisation and can’t work simultaneously. If we take too much brain to concentrate on writing code, we will get lost in design and forget about many important aspects.
There are special exercises that can help with synchronisation. Apparently juggling helps, or listening to some very strange music. However, Pair Programming also helps. It allows one person to focus on the high-level look at the problem without occupying your mind with a low-level issues such as writing on a keyboard and navigating through code.
Does it really work?
A lot of research has been conducted to show the benefits of pair programming or lack of them. The most frequently quoted study conducted at the University of Utah in 1999 says that programming in pairs increases working time by 15%, on average, but it also results in code that contains 15-20% fewer errors. Assuming that it is really true, then taking into account the very large increase in the cost of repairing errors, depending on the time, it will turn out that working in pairs is extremely efficient from an economic point of view.
However, the problem is that the majority of research on this technique doesn’t fulfil the most basic criterion of recognizing them as reliable in the scientific community. They aren’t repeatable, conducted in compliance with a description by other researchers and most importantly, show different results. It was able to repeat the result of a single research altogether.
Conclusions show that seeking for scientific evidence for the effectiveness of this technique or lack of it makes no sense, but it is necessary to try it by yourself, observe results and draw conclusions. I was doing that for the last couple of months and would like to share my observations with you.
Pair Programming in practice
Classical pair programming
Theory says, and my observation proves that this style of working supports creation of better quality solutions. Innately, they are better thought over, better correspond to needs and contain less errors.
This technique ideally suits to solving complex problems requiring a broad perspective, the implementation of mechanisms, in which we expect high quality because every mistake will result in high costs in the future. I am referring to both key system functions for a client and generic mechanisms, which if written in an inconsiderate manner may cause problems.
It is commonly said that this technique is a good tool for solving difficult problems. However, I noted that the word “difficult” may be understood differently. Let me distinguish two types of difficult tasks.
- Difficult, because they are complex – have a lot of use cases and boundary aspects. As I said this type of tasks are perfect to carry out in pairs.
- Difficult, because they are unknown – but if the difficulty of the problem lies in the fact that it requires to learn something new: legacy code, a new library or an external component. Completion of this task mainly means figuring it out in your head, acquiring new knowledge, conducting a series of experiments, etc. There aren’t two people doing it in the same way, each at their own pace and from their own point of view need to handle documentation, and try to write some code only if they are ready for it. Working in pairs is simply not suitable for this sort of tasks. I call it the Pair Documentation Reading antipattern.
Another observation, which I have to share with you, concerns the role of “navigator”, i.e. the person in pair who doesn’t use the keyboard at the moment. His brain is excluded from having to think about the keys, code syntax, but must use that freedom to think holistically about the problem. Consider whether we are moving in the right direction and think about further test cases for implementation. He must decide where we should go next. If, instead, this person focuses on the code, he will simply become a manual spell checker and will be thinking in the same way as the driver. This technique won’t bring us the expected results. It is just as important as the fact that the Code Review process not only focuses on naming conventions, typos and function names, but mainly on the design of the entire solution, potential gaps or included test cases.
Pair Programming as mentoring technique
The second way to apply working in pairs, which in fact I often use, is mentoring.
The main difference between classical technique and mentoring is the goal. In the case of mentoring, it isn’t about getting a better quality of solutions, but to provide knowledge to a mentee.
There is also a significant difference in the way of working. A mentee spends most of the time at the keyboard, so that he would be forced to solve the problem himself, the mentor’s role is limited to giving examples, tips or getting out of trouble. It is advisable to mentor to take over the keyboard from time to time and write a piece of code, but only to make it easier to focus on emerging solution. He must, however, be wary of so-called syndrome of “I’ll show you.” That is the situation when being unable to withstand the lack of progress of mentee, a mentor takes over the keyboard and creates a solution instead. The code is created much faster, but the effect of acquiring knowledge is minimized.
Here the question should arise “Is it worth it?”. Using time of an expensive people to teach a beginner sounds very inefficiently. The typical answer is “it depends”. The more we want to rapidly gain knowledge by novice the more it pays off. Normally it appears in a situation when the beginner has some shortcomings and they will result in inability to made good enough code or he will just be wasting time looking for solutions in the wrong places. If at the same time the beginner will ask a lot of chaotic questions, it may bring even negative efficiency to the project. The solution for such a person may be learning programming in pairs. According to my experience, after this 2-4 hour session, where I wanted to show some work technique, or the library, the novice was able to carry out further similar tasks himself in a good enough way. What’s more, after this session, a mentee was always very motivated to work and further development on their own, which is an additional positive side effect.
Another way of working, which I will write about, was provisionally called Pair Sitting, because unlike Pair Programming, only one person programs here, while the other somehow helps.
It is a popular technique designed to obtain prompt assistance of a competent person, or a joint code debugging. A common problem with programmers is that when they focus too much on the problem, they can’t see the solutions that lie outside a certain area of exploration. The impasse can be solved by interrupting work on the task and returning to it the next day, or by inviting a person with a fresh perspective.
As long as asking for help don’t disturb our colleagues at work, it is a recommendable and very popular technique. I noticed, however, that people seeing the benefits of such support often come to the conclusion that they would go one step further and will work with two people at the same time, in the end it is even called “Pair Programming”. Trap in this thinking is that the person who is to serve as an assistant, but doesn’t write the code himself, loses concentration very quickly.
It even appears that psychology describes this phenomenon as “Attention span”, i.e. the time in which a healthy person is able to focus on one thing. Research indicates that it is 10-40 minutes. My experience is similar, as I observed, after a few minutes of help people begin to lose themselves in the code and don’t bring significant value.
In view of these observations, I would recommend the method of rapid assistance only if it will be really fast. However, if we want to work on something in pair longer, because we want to get better quality, it is necessary to apply classic pair programming, because changes in the role of driver and navigator facilitate longer focus on the created solution.
Violating Intimate Zone
Social psychology defines intimate zone as region surrounding a person which they regard as psychologically theirs. It is about 45cm apart from us and is reserved for lovers, children, close family members and friends. For purpose of this article, I’d extend this definition to “geek intimate zone”, which is extended by one’s environment including deck, hardware and software. Violating both of those zones by unwanted people will lead to natural discomfort and defensive reactions.
Pair Programming often leads to such violation. It may not be the problem if two developers are good friends or just trust each other. However, it is very likely, especially for developers inexperienced in pairing, that this situation creates distractors that will simply not let partners to fully focus on problem they are solving and continuously make their collaboration ineffective.
There is no simple solution to this problem, however, I have some tips, how to minimize its effects:
- Build trust oriented culture in a team,
- Plan your session in advance to get psychologically prepared,
- Make sessions short at the beginning (1~2h).
Additionally, geeks like to tweak their environments by configuring their IDE’s using plugins, automated scripts as well as ergonomic keyboard etc. It is generally good because it should make them more effective, however when those environments are too personalized, other engineers may not feel comfortable, and simple distractor like fact he can’t easily run tests might make their work ineffective, because they are not fully concentrated on solving problem.
Simple solution to this is making sure one’s environment is natural for both programmers. However if not, it may be worth preparing team’s workstation, dedicated to working in pairs.
Pair Programming, as all Extreme Programming techniques, requires motivation and discipline to be effective. Without those things everything can be misrepresented e.g. we can achieve high coverage tests that do not test, or working hand in hand without commitment.
If somebody isn’t convinced that this technique works, it doesn’t make sense to force them. Instead, we can encourage by example; show how it works emphasising results of working in pairs with others, and then gently talk into joining.
If Pair Programming becomes a common technique in a team, and someone still avoids it obdurately, well it will be necessary to consider whether this person fits to the team in terms of culture. Kent wrote in his book: „XP is not for everybody, and not everybody is for XP”.
Above, I’ve discussed specific problems and dedicated solution, now I’d like to suggest two general hints, which will help you to be successful in pairing.
Plan Pair Programming session
Pair Programming session shouldn’t be an unexpected event, because it can cause psychological barrier, especially between new partners. What is more, planning session a day before will let both of you to have time to gain task context and close all urgent issues. As an example, you can have your coffee, read emails, call mechanic and just clear your mind from anything else than problem to solve. Best idea is to identify tasks for pairing during sprint planning and assign people who will be working on them, so they can schedule them as soon as possible.
Additionally, it is good idea to not schedule more than 4-6hours. If you are just starting it may be good idea to plan shorter sessions (~2h). Pair Programming is extremely exhaustive activity when done right. When people are getting tired, they are less focused, concentrated and effective, so at some point it may be better to split, return to the task next day, or finish it solo if it is almost done and only simple cases left.
Pair Programming, as any technique or methodology, has its rules. You may not stick directly to “official” rules, but have your private ones, defined by you and your partner, but you need them. Make them explicit, it is very important when you are new to this practice.
If they are not explicitly said, you both may have problem leaving your comfort zone and just pretend you pair program. If you start pairing with new person, you may be violating his intimate zone (described previously). Setting up rules, may minimize such discomfort, because you both know what you do, how, and what for.
Few clues what such contract should include:
- What is policy of changing roles – e.g. every 5 min, every test,
- What is maximum length of session,
- When you do breaks.
Additionally, remind yourselves important role of navigator.
But first remember:
- You may need to explain your stakeholders, or whoever pays for your work, that you don’t waist “resources”. You might find useful links below.
- Your team need to change leader to introduce it. If you feel to be the one, you need to be passionate about it, need to encourage people, make sure they are empowered and able to fail at beginning. Listen them and advice.
- Before you go with new technique to real life problems, you may want to start pairing afterhours on katas, side projects etc.
Also you have to accept, and probably explain to management, that extra time effort will be required, especially at the beginning. However, this is investment in quality, risks elimination and motivation.
Start slowly, by planning one pairing session per sprint. Observe effects, discuss, draw the conclusions, return to theory, personalize process… be pragmatic! Agile is about agility, not any rigid processes.
- “Extreme Programming Explained: Embrace Change, 2nd Edition”, Kent Beck, 2004
- “Extreme Programming Refactored: The Case Against XP” Matt Stephens, Doug Rosenberg, 2003