Reading an article “Why Pair Programming Is The Best Development Practice” written by User s1369981 I was struck by the arguments for incorporating pair programming into the software development process. Moreover, since the Author sounds very convincing and is into that programming technique, he passes on the enthusiasm. Even though there are already other responses that contradicts his statements, I think he is right… at least partially.
In the first part of this document, I take an attitude towards Author’s ideas about difficulties and benefits of Pair Programming process. I present some of my views on both issues and then generalize article’s punch-line with claim that Code Review practices are the ones that should be used in any software development project. Then I present some facts supporting my reasoning and propose the way how to start performing most basic Code Review variant, namely Peer Review.
3. Thoughts on article:
In the article, Author first starts with information there are many voices saying Pair Programming is bad and doesn’t work for them. Then he claims that the bad experience with this approach stems mostly from the fact it was not executed in a correct way and gives the rules that people should follow.
I haven’t done pair programming before, so cannot speak for myself. However, it isn’t surprising there is much more to it than just not following rules – a human factor. Having read linked resources such as ,  and other industrial research  it seems the biggest problems in practicing Pair Programming are:
– individualism, which cannot be neglected, since programming is seen by many developers as a personal thing;
– scheduling – to realize Pair Programming, developers have to work within same hours and synchronize their days off, which influences their flexibility;
– difficulties to find appropriate partner, so that they would work flawlessly and be compatible in their knowledge (apart from knowledge sharing case, people find Pair Programming fine if they work with programmer of complementary skills, who is smart and knowledgeable or easy going in terms of communication).
In my opinion, given problems cannot be solved with general guidelines. In fact, their importance is dependent on the team, how cohesive it is, how people recognize each other (as knowledgeable, smart, liked, etc.) and how the members get along with each other. If these obstacles are the minor ones, pair programming could work well. Otherwise, it is something that probably fails giving negative results as observed in some teams in  study.
The other part of the article discusses benefits of conducting Pair Programming. The biggest one mentioned is the fun that it gives to participants and helps overcome the boredom that arises while working. Another main benefits given are pretty straightforward. I point them out deliberately:
– many defects and bugs are caught before even introduced, which is a great advantage, and spares the time for bug-fixing and maintenance,
– the knowledge is shared among programmers, what helps improving a team as a whole, thus increasing quality of later code they produce;
– design and code quality is improved, due to the immediate brainstorming, discussion and “fear” of embarrassment.
So, since Pair Programming has such huge pros (especially fun), Author finishes his work with conclusion that it is the best development practice.
First of all, I don’t agree that the programming at company becomes boring. It’s always challenging, otherwise we would be reusing the same code and companies didn’t employ more and more software engineers. There could be some issues, when we are only delegated to code maintenance and bug-fixing. People generally are not satisfied with their work, if no results are visible. When the bug is removed there is probably nobody to praise you. They say that error shouldn’t be there from the beginning. Refactoring… fine, but who notices apart from the team, who gives you credeits? Maybe based on those LOC statistics… In this case I can get Author’s point.
And coming back to pair programming, it could be fun for people who are opened for cooperation, problably as the Author is. There are however humans, who find it very distracting  or psychically fatiguing  to work so closely with others for such a long time.
4. To do or not to do?:
I don’t think that Pair Programming should be always chosen. As stated earlier, it could work for you or not, what depends on the spirit of your team. You have to consider all pros and cons, which basically comes down to evaluating the eagerness of your team mates and convincing the management level (answer their question: why to pay for two programmers doing one thing, when we could hire outstanding one for such salary?). Take the problem really seriously, since there is a long adaptation period (could be few months, ), until this approach pays off. If the wrong decision was made, these are the months you lost on bad performance and maybe some smell stays behind due to programmers misunderstandings and arguments.
5. What is left then?:
But what is there, if you find that Pair Programming is not a solution for you? Do you have to throw away all the benefits it provides? The answer is “Of course not!”. Pair Programming is just an extreme of the set of practices that are called Collaborative Techniques (for a very good overview, see ). You can choose from others like formal inspection, informal technical reviwes and document reading. Personally, I think that you should pick one of these if not Pair Programming. Everyone can benefit from collaboration, the statement supported by Rubber Duck Debugging  method (another extreme, collaborating with virtual peer) and numbers:
“testing alone has limited effectiveness — the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent” 
The code inspection is said to be most effective method, but results of other approaches fluctuate around same value. The code reviews methods are used by such giants as IBM, AT&T and many more (if not all successful companies). Remember that finding a bug in the source code is being given on a silver platter. Getting to it in the later stages of process developement, means necessity of tracking it from effects it causes.
6. Getting started with Collaborative Techniques:
Even if your management doesn’t see it necessary to reserve slots for collaboration, I would strongly encourage you to start small – find a “buddy” that does code review with you. You would improve your skills, detect bugs and this is fun – because constructive discussion is fun! And it’s not that difficult to carry out basic code review, if for instance you are using github or bitbucket. Open particular commit of a file, and if you find something worrying, write a comment to the line of concern. The code is not spoiled with anything You write, your peer gets that information and discussion is started. And you both may come up with new ideas. Two heads is better than one. If you still hesitate or have some doubts, have a look at the blog .
All in all, I think that Pair Programming is great, however it’s not a silver bullet that should be used by everyone. It has some alternatives among Collaborative Development Practices, which may even perform better. Your project needs to analyse all pros and cons of every of them and choose the best fit. Your code should be reviewed by others, because this way it will get better.
 Why Pair Programming Is The Best Development Practice? http://blog.inf.ed.ac.uk/sapm/2014/02/17/why-pair-programming/
 A. Cockburn, L. Williams. 2001. “The costs and benefits of pair programming“. In Extreme programming examined, Giancarlo Succi and Michele Marchesi (Eds.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA 223-243.
 A. Begel, N. Nagappan. 2008. “Pair programming: what’s in it for me?“. In Proceedings of the Second ACM-IEEE international symposium on Empirical software engineering and measurement (ESEM ’08). ACM, New York, NY, USA, 120-128.
 H. Hulkko, Abrahamsson, P., “A multiple case study on the impact of pair programming on product quality“, Proceed-ings of International Conference on Software Engineering, pp. 495 – 504, 2005.
 Pair Programming vs. Code Reviews, http://blog.codinghorror.com/pair-programming-vs-code-reviews
 S. McConnell. 1993. “Code Complete: A Practical Handbook of Software Construction.” Microsoft Press, Redmond, WA, USA.
 Rubber duck debugging, http://en.wikipedia.org/wiki/Rubber_duck_debugging
 Simple way to do code review, http://guides.beanstalkapp.com/collaboration/code-review.html
 Pair Programming – My Personal Nightmare, http://www.bennorthrop.com/Essays/2013/pair-programming-my-personal-nightmare.php