“Let’s do some pair programming!” – this phrase may one day discourage you from working in your dream software company.
There are many claims supporting extreme programming and pairing in general, but you think that this is not for you.
If you believe that working solo is the best way for achieve great focus in a creative process known as software development…
YOU ARE WRONG!
Cowboys ain’t fun anymore
Recall your best programming experience. Do you remember when ideas were flowing through your head, hours were passing as seconds and you were experiencing constant feeling of a muse sitting next to you?
You might have experienced this several times, but unfortunately not very often. You probably think about programming as a creative process – sadly this is not relevant for every task. What about when you were working on bigger project? Interesting and creative core part was finished very quickly, but what was left as boring and extremely repeatable.
Guess what – your most programming tasks in a software company will focus on boring and repeatable tasks with very few of them being creative and challenging. Your performance will be measured by number of implemented features, lines of code and bugs fixed. In addition hard work will be valued much more than talent on its own. You will not feel productive and creative every day, but you will have to submit your results anyway.
Cowboys are of no value anymore. Heavily trained spec-ops of extreme programmers are.
Not even once!
Now we should hear some arguments against pair programming. Let’s start big :
“One of the most influential programmers (if not people) in the world, Steve Wozniak, famously advocates”:
“Work alone… Not on a committee. Not on a team.”
You might also add that some of the greatest minds in our history were introverts and they achieved great success by working solo (Darwin, Einstein, Newton). Of course you won’t mention the fact that those world-changing inventions were then developed, tested and introduced by dozens of scientists, engineers and businessmen, but it sounds like a good point against pairing in general. Lastly you may mention that about 30% people in the world are believed to be introverts  (and probably even more when we think about programmers), so pair programming must be a practice introduced by extroverts to control a process of software development.
Every claim mentioned above is probably true. We can all agree with them, but it doesn’t change values which may be gained from working together.
Let’s change our direction a little bit. Ask yourself extremely important question:
Have I ever tried pair programming?
If the answer is no – you should stop reading and try it. If yes and you are still not convinced – go to the next section. Maybe this is a case that you are doing it wrong.
Pair Programming 101
There are tons of examples and blog posts on the web of people sharing their bad experience when practising pair programming. There are thousands of stories of how evil pairing is and how wrong it is for creativity[1,3].
Let’s stop this. I believe that those stories exist, because people have no idea how to practice pair programming.
No one was born the best programmer in the world. People who are believed to be ones, gained their knowledge through hard-work, experience and hours spent on coding. The same goes with Pair Programming and social skills in general. Everyone needs some training.
Let’s consider some of the most important rules :
- Pairs should be formed flexibly and naturally, rather than by fixed assignment.
- Keep fresh perspective by switching your partner frequently.
- Sit comfortably (with plenty of space for your feet and arms) side by side.
- Always use a big monitor (or more) and two keyboards.
- Collaborate with your partner, do not critique his work
Following those four important points should help you achieve success when working in pairs. In addition, we should consider a little bit more.
Pair programming is an important and crucial part of Extreme Programming (XP) methodology. This being said, we cannot use pairing without following rules from XP.
What XP tries to do, is to enhance team software development process, rather than single programmer process. XP shines in every piece of software that must be maintained (eg. development code). It means that spiked, innovative solutions may benefit much more from different approach (eg. happy hacking).
Let’s think about Test Driven Development – it was invented to simplify and control development code with hundred (thousands) line of code. TDD works as milestones – one test resolves one problem. This means, that it give structure to your (unstructured) flow of thoughts.
As mentioned before, XP is team software development methodology. In a team everyone is average (or as good as weakest member). In order to make people better, we must follow a strategy when matching people into pairs. Let’s try to match people with the same skills in the beginning. Later on we can try junior plus senior programmer. This however must be realised with cautious – let’s give junior time to research important part of the project, which no one is expert in (eg. library). We should make everyone feel like an expert!
Last, but not least is to practice proper ways of communication. You may say that during pair programming people may start arguing or feeling bad. I will tell you – this is a problem with your team. Teambuilding is important, the same as practicing good manners. If we resolve this – we will resolve every problem.
We need a proof my dear Watson
There are plenty of articles, research and blog posts supporting pair programming. Pairing is all about collaboration and teamwork, thus it will shine when following aspects are considered [5,6,7]:
- A huge percentage of bugs and defects can be caught before release.
- There is a lot of knowledge sharing and project ownership involved in the process.
- Code design improves with significant reduction of number of code lines.
Those points will serve as a something well defined and thoroughly researched. In addition several well-known and respected programmers prefer pairing [5,6] and even more experienced developers may benefit from learning a new ideas.
The biggest objection against pairing is that it doesn’t leave you time for though. Demarco and Lister, in their experiment  found that the best factor for quality is not money nor experience, but how quiet the workplace is.
On the other hand, according to  people who are practising pair programming are experiencing flow (productive state of mind) more often and are experiencing less interruptions than solo programmers.
As the last proof, let’s hear some comments from people who used pair programming :
“The adjustment period from solo programming to collaborative programming was like eating a hot pepper. The first time you try it, you might not like it because you are not used to it. However, the more you eat it, the more you like it.”
“It is psychologically soothing to be sure that that no major mistakes had been made . . . I find it reassuring to know that [partner] is constantly reviewing my code while I drive. I can be sure I had done a good job if someone else I trust had been watching and approved.”
Is there an ultimate answer?
Yes! There is an ultimate answer to the question “Why Pair Programming Is The Best Development Practice?”. However the answer is a tricky one:
Pair Programming is the best development practice, because it is fun!
Pairing is not most suitable in every situation nor easiest one and probably not even the most effective one. It works well, shines in standard team software development, produce good results and strengthen team spirit. However the most important argument is that pair programming gives us a lot of fun, knowledge sharing and motivation in imagined-as-single-person task such as programming.
- Schat, Sean. “Quiet: The Power of Introvert in a World That Can’t Stop Talking.”Brock Education Journal 22.1 (2012).
- Shore, James. The art of agile development. ” O’Reilly Media, Inc.”, 2007.
- Cockburn, Alistair. Agile software development. Vol. 2006. Boston: Addison-Wesley, 2002.
- Cockburn, Alistair, and Laurie Williams. “The costs and benefits of pair programming.” Extreme programming examined (2000): 223-247.