Tuesday, October 18, 2005

Pair Programming: Issue 1: Space Violation!

A colleague of mine suggested I blog something on why I am an advocate of Pair Programming (PP) - he is somewhat of a skeptic. He mentioned some unfortunate incident with an insect and an orifice.

I'm going to try and avoid reiterating the papers or data you can find on the web like http://www.pairprogramming.com/ or any of the wiki sites. Rather I'm going to make a statement, and address four concerns he raised in four separate blogs over the next few days.

Statement: I have seen Pair Programming work over and over in many circumstances and that is why I believe in it. To me it is the primary mechanism upon which successful Agile depends. It is the only execution practice which is first and foremost about people and their interactions, all the rest are technical (Stand-Ups are an organization practice to me)

Issue 1: People generally do not like to have their personal space violated, whether it be their physical space or intellectual space.
I find this a worrying view point, but not an unusual one. Many developers consider themselves to be owners of a physical or intellectual place that they need to defend against violation.

One of the big shifts in adopting an Agile stance is the attitude change from "my" to "our". Traditional: My code, my space, my goals, my tasks. Agile: Our code, our space, our goals, our tasks. And not just in words, but in actions. Pair Programming is the practice that helps most with this my-to-our change. I suppose initially it is the very violation of the "my" attitude that PP demands that causes the change in itself.

I advocate teams setting a side a set of shared machines and space to start pairing. In this way you can get around the "my" space issue and the space becomes "our" place to develop. Equally the machine used for development should be a consistent development environment that is not personalized to an individual. If you stick to discipline of PP with pairs regularly swapping partners and machines a lot of the "my way" behaviour fades away (coding styles, dev environment set up, my IMs, my email, etc).

Still having some personal space is important! 10 years ago the "cave and common" architecture was a hot topic, and I believe this is appropriate for Agile teams. This "special space" is often criticized as needing more space. However, it is possible to fit into the same space by halving the personal desk area and using the space for pairing stations.

So what about the "intellectual space" violation? Well being extreme about it, I believe it is irresponsible and unprofessional for a developer to defend an intellectual corner and expose the client to the attendant risks. I often describe the problem as "getting run over by a bus" - in the traditional defensive model a project can fail if one developer gets run over by a bus. In a Pairing project feasibly all but one of the developers could die in a bus crash and the project could still continue. Fatuous? It does happen: I was told only the other day of a real incident of a "key" developer dying during a project and it causing terrible consequences (beyond the obvious trauma).

There is a fear associated with PP about exposing your knowledge and losing control of your position through sharing. I have never seen this happen. If anything it can help strengthen your place as exposing your skills helps others appreciate them more. Further, by needing to explain your thoughts I find it deepens your understanding and cuts through the fluffiness of thought to get things over to your partner. Also, pairing is a two way street: think of it as an opportunity to gain new skills !

One way of looking at the traditional reaction to own part of the system or own part of the project intellect is that it is a way for developers to try and demonstrate their personal worth to the project and team. I saw the detriment that long-term PP had at Connextra where the value of the individual faded into the background of "the collective". Consequently we created the Gold Cards practice as way for individuals to have time to show their individual prowess. Just as there needs to be personal physical space, there needs to be personal project task space.

On a slightly different note: PP is the way in which collaborative behavior becomes visible to stakeholders. How else do you show that collaboration is really happening?

I find it curious that everyone is bothered by Pair Programming but rarely picks on Shared Code Ownership -with respect to the my/our change. I wonder if this is because they interpret Shared Code Ownership as "access to your code so I can change it" rather than it being "our code"?


At Tuesday, October 18, 2005 9:02:00 pm, Blogger marc said...

Excellent post, John. I will digest it and come back with some comments.

At Tuesday, October 18, 2005 9:15:00 pm, Anonymous Chris Donnan said...

Hey there - this is Chris Donnan - a new add to Finetix NYC. Mark Adler is sitting beside me and pointed me to your Pair Programming entry herein.

I will say that I am a huge fan of pair programming, with a few years of practical experience. I will say that in the past we tended to use pair programming selectively, but very often. We used it certainly to help get new project resources into what was going on. This was especially helpful when working in a highly patterned environment. It is much easier for devs to refactor code into the common patterns once they have seen it/ participated in it in a pair. We also used it extensively to make lower level or mid level developers get up to speed and just plain learn. If the lower resource was coding or the upper, it was always beneficial to the project and both developers. We also used it on 'key areas' of our applications. When working on especially tricky bits - having 2 brains together just results in better, less error prone code.

I can honestly say that most of the best work ever done has occured during pair programming. Even having 2 upper level developers sitting together is very productive and just results in better code without fail.

I can only imagine that pairing all the time - as opposed to much of the time would continue to contribute to the bottom line of all projects.

Anyhow - I hope that we can get more and more people on board with agile practices in general.


At Wednesday, October 19, 2005 12:43:00 pm, Blogger marc said...

One of the things that I was wondering about was how you reconcile PP with mobile programming. There are people who like to load up their laptop with the current build, go home, and program for another few hours. People tend to be fairly productive out of the office, when total concentration can be given to design and coding. Also, at home, people might want to tinker with new ideas, away from the master source code repository.

At Tuesday, October 25, 2005 10:14:00 am, Blogger John S Nolan said...

"Most productive"...hmmm. Writing loads of code without being "slowed down" by a partner is not necessarily productive. Having unpaired code means there are parts which are not really "certified" via the pairing process, so are of questionable quality. Singlehanded code of questionable quality will cause slow downs at later points through unfamiliarity and the inevitable bugs. It might seem productive now, but on the scale of the project it will bite you.

HAving siad that, i wouldn't want to cut off this enthusiasm developers might have for "doing things at home". But its how this is integrated back into the whole. A similar effect happens with Gold Cards where you sometimes need to adopt independently produced solutions - this then becomes a pair task of integration.

Mind you - if you've really been pairing at full tilt I'd be surprised if there's enough energy left to do stuff at home...(maybe I'm just getting old). I've always seen it as vitally important for there to be downtime for developers - like good music, its often the gaps that make it better. 40 Hour weeks and no work at home or weekends is my target behaviour.

At Wednesday, November 02, 2005 4:26:00 pm, Anonymous Nat said...

Programmers are often more productive at home or after work hours because the office environment is not set up to support programming. Most offices seem expressly designed to reduce the productivity of programmers as much as possible.

This is especially true when working alone because programming then requires deep thought. Programmers must get into a flow state, which takes up to an hour but can be disrupted in an instant by nearby conversations or phones.

Pair programming helps because you enter a different kind of flow state, one of conversation not concentration. I find this state is much less fragile in the face of temporary distractions.


Post a Comment

<< Home