Agile Zone is brought to you in partnership with:

I wrote my first program in Z80A when I was 14 on a ZX Spectrum and ever since I have been hooked. I love writing code of any flavour as well as being passionate about the coding process. I have worked professionally in the software industry for the last 15 years using Microsoft Technologies, and I code at night in PHP, HTML, Javascript and CSS. Chris is a DZone MVB and is not an employee of DZone and has posted 34 posts at DZone. You can read more from them at their website. View Full User Profile

Agile Decompiled: Pair Programming

06.18.2014
| 7367 views |
  • submit to reddit

Pair Programming is a practice which is associated with agile development but is in fact a practice from the Extreme Programming movement. If you are not familiar with pair programming then the idea is two people share a computer, mouse and monitors and pass control back from one person to another as part of the development process.

Woody Zuill has taken this idea in an intersting direction with his practice of mob programming. Some practionioners, including Woody use the idea of a navigator and driver when pair programming. This is where one person drives, and the other person or people say what direction the code show go in. In a pair programming scenario, in practice, the driver also has some input.

Now if you have ever studied the process of writing you will be aware that there are two ‘modes’ the brain works in when writing something, even as simple as a short email. The two modes basically break down into a creative mode and an editing mode. Often cited as the best way to write is to get something down on the page, while not worrying about grammar, spelling and the turn of phrase. This allows you, as the author, to get into flow and get your ideas down. You then go back and look at the piece of writing and in the second mode, edit mode, you’ve guessed it, edit what you have just written. Correct the grammar, spelling and re-working sentences so the whole peice flows better.

Now coding is very much the same. When you code you should first be in creative mode and then go to edit mode and refactor your code. This is partly why TDD is successfull because it gives the coder a better opportunity to get into flow. But what would happen if you could split your brain in two and be in both creative and edit mode at the same time?

This is one aspect of what pair programming can give. Yes, each person in the pair may well learn something different from the other person. And yes the liklihood of mistakes in the design may also go down. But in my opinion it is the ability to be in the two modes simultaneously that can give you speed.

However there is a downside and that is perception. Pair programming still suffers from the perception that if two people are sharing the same keyboard and mouse then only half the work is getting done.

From where I stand I would say that pair programming can work, however there is a lot of debate as to whether the cost of pair programming is worth the benefit? For example there is an excellent analysis by Dave Nicolete on does pair programming work and also some interesting discussion on the Cunningham & Cunningham, Inc. site.

Like many agile practices my personal opinion is that pair programming should be seen as another tool in your coding toolbox. When a hammer is the appropriate tool to use, use it.

Do you pair program? Or maybe you are thinking about pair programming where your work? If so then please leave me a comment as I would love to hear about your experiences.

Published at DZone with permission of Chris Odell, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Dave Glasser replied on Wed, 2014/06/18 - 10:20am

 Well, since you asked for an opinion, mine is that pair programming is a monumentally stupid idea. It's like having first-graders pair up and hold hands in a "buddy system" on a field trip to the zoo. It may provide an illusion of productivity for the weaklings on a team, and I suspect that in many instances, that's its actual, unstated purpose.

I don't think that two B-grade programmers working in a pair will ever produce better code in less time than a single A-grade programmer. Of course, programmers should collaborate and exchange information freely wherever they see the need, but to have pair programming imposed from the top down is laughably ridiculous, and is anything but agile. (And I'm using the word "agile" as a generic adjective here.)

Camilo Rivera replied on Wed, 2014/06/18 - 8:53pm in response to: Dave Glasser

@Dave How did you get to this conclusion? Have you had any experience with Pair Programming?

Dave Glasser replied on Wed, 2014/06/18 - 11:40pm in response to: Camilo Rivera

I have shared a keyboard and monitor with other programmers on a number of occasions when a particular situation called for it. I call that practice "Collaboration."

My conclusion is based on a decade and a half of experience cranking out lots and lots of code on various teams using various methodologies. Some of my most valuable learning experience was working on two massive, high profile projects that failed spectacularly due to mismanagement and blind adherence to the flavor-of-the-week methodology. And a lot of dead weight on the teams, also.

Based on my observation over the years, my conclusion (which I don't find particularly encouraging BTW) is that the most important factor in the success or failure of a project, or just the quality of the end result (success is not always a binary value) is something these eXtreme Scrum-Ban/Pair-Kan peddlers virtually never bring up. That is the skill level of the developers. If you have the right people writing the code, combined with a light touch by project management, you don't need all the ceremony and ritual of the so-called "Agile" practices.

Average programmers will create code of average quality at an average pace. Every single time. There is no way around it.

A really good, top-tier developer will not be made more productive by having some pair-buddy that was assigned to her by some manager sitting next to her "driving" or whatever the hell it is they do. She'll be less productive. Of that I have no doubt.

Whenever I read about how great it is to have an "extra pair of eyes" spotting bugs, etc. I think to myself, "gee, it sounds like writing software is a real struggle for these people." I've encountered lots of those people over the years. They tend to accumulate in enterprise IT shops, where, in many cases, an employee can't be fired simply because they're not very good at their jobs, and managers, bound by some ancient corporate salary matrix, can't pay enough to attract really excellent developers. Ironically, though, these big companies can often find the funds to hire Laetrile salesman (consultants, "coaches", etc.) to hopefully make their lackluster teams more productive.



Chris Odell replied on Thu, 2014/06/19 - 8:52am in response to: Dave Glasser

Thanks for your comment Dave, I think it's good to have both sides of the story. My take on a lot of these agile processes is that a lot of people get very religious about them. And I think you have to judge which processes best fit your team/corporation/culture etc. in a more objective manner. 

The series of articles I have written over the last few weeks are derived from both experience and research, and my own attempt at making sense of some of the processes used in various 'agile' flavours.

Dave Glasser replied on Thu, 2014/06/19 - 7:04pm in response to: Chris Odell

 I just checked out the link on "mob programming". Sheer lunacy. When will it end?

Robert Brown replied on Wed, 2014/06/25 - 11:38am

I think the general premise that we have two modes is correct.  Creative and edit.  However, doesn't it makes sense that the creative mode needs the flow and unbroken creativity to be effective and that having someone say "Wait you mispelled that", or "But if we break this out into a function we can reuse it" breaks that flow?  

I admit I've never worked in a situation where pair programming was forced on us.  I've worked plenty of times with others on a tricky troubleshooting job, or where we're trying to brainstorm out a way to accomplish something, but in the troubleshooting we're both in edit mode, and in the brainstorming we're both in creative mode.  So the premise that one person is in one mode and the other is in the other is IMHO flawed .



Milos Silhanek replied on Wed, 2014/06/25 - 4:09pm

As usually when is written about some topic people think it is the "silver bullet". I have read some article/book. The new reade was made think the pair programming is the only method to apply.

Each tool is useful under specific conditions. 

I have enjoyed pair programming many times: one with the global knowledge of the business domain and I created the algorithm during a discussion (it was such a brainstorming), I wrote it as a comment and then we implemented it. We both added some ideas, detected a difficulty or alternative flow, error possibility and I had a technology knowledge. I have enjoyed it in vice versa roles.

As I wrote in the article http://java.dzone.com/articles/pair-programming-disadvantages:

<cite>Pair programming is useful - cases described by the article - the analyst knows what and the programmer knows how. Then the cooperation is a synergy. - when you need any dr. Watson to explain your problem.</cite>

It was very effective, creative, amuzing and we created it well.

Milos

Chris Odell replied on Thu, 2014/06/26 - 3:50am in response to: Robert Brown

Good point. I think you are correct that when the other person in the pair stops the person who currently has the keyboard then that person drops out of flow. However while the person in flow is typing, I would argue, that the other developer in the pair can spot or at least think about what could be re-factored, what could be improved. Kind of like a continuous peer review if you see what I mean?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.