What are possible disadvantages of pair programming?

Question

Pair programming is quite famous now-a-days.

It has several advantages like:

1. Programs with fewer bugs.
2. Post production maintenance cost is much less.
3. Established practices are challenged resulting in emergence of new ideas.
4. Programmers learn from each other.
5. Programmers develop soft skills.

But what are the disadvantages of pair programming?

Answer 1

Although pair programming has gained considerable reputation, it has several pitfalls too.

Some of them are as follows:

1. In pair programming you cannot sit back and self-evaluate your own code.
2. One of the pair may stop being actively engaged.
3. The driver needs to "program aloud". Silently programming reduces the benefit.
4. It costs more man-hours to produce the same features. Balance must be maintained between quality of code and increased coding cost.
5. A "watch the master" phenomenon may arise when an experienced and a novice programmer pair up. The novice member may become the observer with the experienced member completing most coding.
6. When two experienced users pair up, a "developer's ego" phenomenon may arise, with each member trying to push his/her own ideas.

Answer 2

I've attempted pair-programming several times, including in an organization that (briefly) considered rolling it out as a mandatory process for all engineers (you can guess how well that idea panned out). Personally, I hated it.

The reasons I list below are only my subjective experiences, and I cannot 'measure' their impact in concrete terms. But here they are all the same:

1 - Having a 'navigator' and a 'driver' only helps if the former is vocal and the latter will listen.

We've all met developers who are stubborn, zealous about some theoretical concern or pathologically unable - psychologically - to 'throw away' old work when someone suggests a problem with it. And we all know individuals too timid or diffident to raise concerns or suggest corner cases.

When these kinds of developers are paired, the navigator quickly takes a passive role, and what you end up with is sole-programming with an automatic code review. This is a monumental waste of resources.

2 - Pairing prevents creativity.

Contrary to what was formerly felt about the value of 'group brainstorming', the consensus these days is that creative knowledge work requires independence and autonomy. When you're working alone, you can quickly hack together some crazy idea to see if it's actually feasible. You can wordlessly assemble some strange prototype, and if you fail, it doesn't matter, because no-one knows.

Compare that to pairing: when I want to try out some new concept, I have to convince my partner, talk them through the implementation, step-by-step, and hope that they won't judge me if it fails. That kind of environment is toxic to creating new ideas.

3 - Lowest common denominator design.

When a pair cannot spin up new ideas, as above, or when the individuals cannot agree on some fundamental principle of how a feature should be designed, what comes out is a muddled design that attempts to compromise and satisfies no-one.

If you pair a developer who builds wonderful, eloquent, skyward functional programming abstractions with a fast-and-dirty performance freak, the code they'll together produce will typically be neither terribly elegant nor particularly fast.

4 - Lack of autonomy and violent transparency.

Violent transparency is a phrase I've plucked from a moderately famous (and quite controversial) polemic against the Scrum methodology. It describes the way that some organisations infantilise developers and treat them with the suspicion normally reserved for non-professional workers.

Whatever you think about the 'harms' of making developers' work entirely transparent (and you may not agree it is actually a harm), many individuals value their autonomy and their ability to work alone, trusted to do the right thing. It's an important psychological need, and to force developers into pairing (as I've seen happen in at least one shop) will leave employees dismayed, upset and alienated.

5 - Some developers just don't play nicely in pairs.

Some people won't or can't conduct themselves appropriately in a paired environment. They may have bad hygiene, poor working habits, an abrasive personality, a 'loud' and 'intense' manner, or a whole host of other attributes that make them fine individual workers, but poor pair programmers.

Can you solve this? Not really. Changing personal behaviour is tough. A pair-programming shop needs to be very careful about hiring and invest a lot of time into seeing how someone works and whether they'll be able to work well with their peers. Discriminating harder on personality, however, means that hiring will take longer unless you loosen your standards on skills and expertise.

Answer 3

Depends on your situation or perspective.

Pair Programming is good for the organization. But is it good for the individual?

After all it's a cost-saving (early feedback) and productivity method; It's not about you but the project, product, company ($$).

Although you can have personal benefits, they are not the reason or end of any development methodology. (Full time) pair programming, for example, also stops you from slacking, surfing etc, you have to justify your pauses to your partner.

Your (rotating) partner will be the best surveillance camera: work intensity increases.

Or, by distributing knowledge the individual becomes less risky to the company (e.g. cannot leave the company with essential knowledge) and has less "bargaining chips".

I'm sure you find more points by reading affirmative articles more critically from YOUR real situation/standpoint in the company rather than from the perspective of your manager.

Almost all methodologies are written from the manager's perspective.

Answer 4

1. Suddenly you now have to tell someone when you want to go to a toilet or grab a coffee. At least there is no need to ask for permission.

2. You have to cope with the other person's hygiene standards.

Answer 5

In addition to other answers:

1. Many companies I've worked for issue their programmers with laptops (based at clients' site - easier to keep equipment safe if taken home after work, being able to do the odd job from home on VPN in a pinch, etc.) Many years ago I already had problems to see on another person's (the "driver" 's) laptop screen from the shoulder surfing perspective - age will not improve this (and some screens become hard to read outside the ideal viewing angle in any case).

   So pair programmers will need sufficiently large screen(s), which will increase hardware cost and limit adaptability to location. May not be a problem for some, in other instances it will be a problem.

2. I have also found that differences in personal hygiene preferences (including smoking, eating and drinking), as well as personality clashes, are bound to hamper productivity. It's easy enough to tell two programmers to "suck it up and get along", often this will result in people rather keeping their mouths shut and silently sabotaging each other via passive-aggressive actions to vent their resentments of each other.

3. Noise. I, for one, like a quiet working environment. I can't imagine the constant chatter from some groups of pair programmers (as you need to talk for communication). Even vocal music on my headphones tends to interfere with my concentration (bland instrumentals for office listening...). I guess this can be mitigated by moving away from the ubiquitous open-plan office to dedicated 2-person office rooms, but that's going to drive cost up again.

Anecdotes for your amusement:

• A previous employer once got a contractor in from another country (all to remain anonymous to protect the guilty). The employer provided accommodation but not transport. Since said contractor lived along my route to work, I got volunteered to pick him up and drop him off again. Let's say his personal hygiene was not on the same standard as what I am used to, and he also smoked heavily ("the strongest!") while I don't. On our 15-min trip to the office I kept my window rolled down - even in winter - which did not prevent my car from smelling like a stale smoking room after the colleague's 3-month stint (no, he did not smoke in the car, but he did while waiting for me).
• We also did not do pair programming, but sat next to each other at a conference table (for a time). After about a month, there was a nice brown ring on the table's faux wood around the position of the colleague's mouse hand. At that point I got an open desk right next to the call-center open-plan-area, which I preferred (with some help from my headphones).
• Then there is the ubiquitous office beverage: coffee. Although I do drink it, I can get along without and do not drink as often as other co-workers may. Breaths at close range can be quite unpleasant - similar to the empty forgotten mug smell. Let's call the fragrance "muggy"...

Answer 6

I think pair programming fails for social and practical reasons. Essentially you are asking one person to work under constant surveilance and the other to do nothing but poke holes.

What inevitably happens after a while is that the pair split to 'check emails' or 'you carry on ill check on that live issue' etc

Rather than improve code output the volume is decreased. Both for practical reasons 'I need to goto lunch/meeting out of sync with you' and social 'Ill just wait for bob to finish what hes doing before I ask about pairing up again, I dont want to be seen as nagging him'

As for the vaunted advantages, there are many common practices which achieve these in more simple and effective ways

Answer 7

Telling two senior developers to do a "pain programming" if they are confident one can do the job is imo on of he biggest disadvantage.