In my experience we've been pretty good at adopting XP. We agree, by and large, that co-location is a good thing. We seem to have difficulty agreeing a coding standard, but mostly we do. We struggle with writing unit tests first - often we are writing tests to hit a “coverage target” and after the fact, but again most people agree we need to write automated tests. We agree that we need to integrate more often, requiring automated integration tests and the adoption of a continuous integration system for our products and this doesn’t generate too much debate.
But after twenty years of extreme programming practices, the one practice that seems to have the least widespread adoption is Pair Programming.
So why don't we pair?
In my opinion our resistance is rooted in three different causes; Organisational, Personal and Societal
Organisational Resistance
Halving our number of people
Simple. We cannot afford to have two people working on one thing. We couldn’t be efficient doing pairing. Many managers just can’t see the sense in it.
Rewards, Recognition and Promotion
All our corporate models for reward and recognition are based on the individual, not pairs. From performance reviews to bonuses, remuneration and promotion, all these are based on the individual. You are given your task(s). How well you executed these tasks and the more of them you get done on your own, the better you are rated. This feeds into your exam/evaluation results. Ultimately your personal results and successes are reflected in higher monetary return. Most jobs and most industries are set up along this "Motivation 2.0 Model" – the better you do, on your own, the more reward you will have coming to you. If you need help, that kind of counts against you.
Personal Resistance
Loss of Freedom
A big challenge to overcome in pairing is the perception of giving up a large part of your personal freedom in work. The day we joined a company we were given a desk - your desk, your own piece of real estate. You are told when you are expected to be in the office but how you manage your time in the office is your business. You dictate when you go to the bathroom, when you take a 5 minute break to browse the daily paper or use social media… There is great satisfaction in having that autonomy and freedom within the confines of a professional environment.
When we pair there is sense of obligation to be at either your desk or your pair partner’s desk during the working day. You will have to excuse yourself when you need a break. You perceive that you are accountable, on a social level at least, to someone else.
Arrogance
You’ll be the one giving everything and you'll gain nothing in return. You feel that your expertise is getting diluted and it's the main reason you're valued by the company.
Imposter syndrome
Can you live up to your own reputation in the eyes of others. You are an Engineer with many years experience and many projects behind you, but they are all on older technologies.
Social difficulties
Pairing is socially difficult. You are forced to work closely with someone you might personally dislike either for physical or psychological reasons. We are social animals and we all carry our own biases, conscious and unconscious. We all have our own personalities and we tend to like people with similar personalities and dislike those that are different.
Societal resistance
The vast majority of roles and jobs in our society do not use pairing. In fact there are a only a very few roles where pairing is widespread and established. A quick google test of “jobs that are done in pairs” returns jobs for “au pairs”, something entirely different. This means in general people are not well equipped or well practiced with the skills that pairing demands on the participants.
Introducing Pair programming to your organisation
To successfully introduce pairing to your development organisation, you have to design your change program to address and overcome all these aspects of resistance. And for some people their resistance is so established in their minds, that it will take a significant effort to bring them on board.
Thanks to Contributors: Shane McCarron, Rachel O'Toole
