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"?