22

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?

closed as too broad by Telastyn, Robert Harvey, Bart van Ingen Schenau, gnat, Daenyth Aug 8 '16 at 12:24

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Is the “parallel” in the question title a typo? – 5gon12eder Aug 7 '16 at 23:06
  • 14
    You mean other than the fact that it takes two people to produce the same (maybe less) output? – Robert Harvey Aug 8 '16 at 1:57
  • 4
    @ThorbjørnRavnAndersen It's probably less. – Robert Harvey Aug 8 '16 at 2:00
  • 4
    @ThorbjørnRavnAndersen Something is wrong with your math. Basically, what you are saying is that you're constantly in peer/code review. It's hard to imagine how that is more time-economical. – Robert Harvey Aug 8 '16 at 2:07
  • 5
    That can be accomplished quite readily without the distraction of a full-blown Pair Programming arrangement. Just work with your fellow software developers in this capacity on an as-needed basis. – Robert Harvey Aug 8 '16 at 2:13
28

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.
  • 4
    2 and 5 can be countered with Ping-Pong Pairing (switching roles between driver and navigator very quickly in lock-step with the TDD cycle: Alice writes failing test, Bob writes code to make test pass, Alice refactors, Bob writes failing test, Alice writes code to make test pass, Bob refactors, Alice writes failing test …). That way, driver and navigator switch roles every couple of minutes at the latest (more like tens of seconds), and every member gets equally large and important tasks. – Jörg W Mittag Aug 7 '16 at 23:02
  • 5
    4 sounds obvious, but I'm not sure. Catching bugs and getting feedback early, for example, may (or may not) actually make up for the doubled developer hours. – Jörg W Mittag Aug 7 '16 at 23:05
  • 4
    @JörgWMittag (re: Ping-Pong pairing) sounds like a recipe for a very stressful work day :/ I hope I never have to program in a place where they enforce this or any kind of strict pair programming methodology. – Andres F. Aug 8 '16 at 0:35
  • 4
    Ping-pong programming requires the two involved to be essentially interchangeable. I have a colleague where the only sensible pair programming combination is having him think and me type (and ponder). It helps him keeping focus and me understanding what is going on. – Thorbjørn Ravn Andersen Aug 8 '16 at 2:01
  • 3
    You could also mention that quite some time is wasted discussing trivial details while in code reviews you can focus on important aspects only. – Giorgio Aug 8 '16 at 6:11
24

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 despised 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.

  • 3
    While I do like the phrase "violent transparency", it's been my experience that the preferred methodology (scrum / agile or something more traditional) has no relationship to whether developers are treated like professionals or not. Dysfunctional organizations will treat professionals like children whether they (pretend to) follow Scrum or CMMI. – David Aug 8 '16 at 12:29
  • 1
    "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.": It is not only about judgment, it is about speed. You do not want to be distracted when you have an idea, you want to write down as much as you can as long as you are in flow. Pair programming actively prevents you from doing that. – Giorgio Aug 8 '16 at 17:49
  • 1
    After you have written down all your ideas, you can tidy them up, maybe the next day and, after that, let a colleague do a thorough review, e.g. on a tool like review board, so they have all the time to look at your finished ideas and think about it with no time pressure. Pair programming also prevents this because it tries to combine coding and code review into one activity. – Giorgio Aug 8 '16 at 17:51
  • 2
    @Jimmy: If you'd written five answers instead of one answer with five points, you would get five upvotes from me. – Giorgio Aug 8 '16 at 17:52
  • Absolutely agree that experimenting requires work that is silent and fast - the exact opposite of what pairing demands. Perhaps pairing works fine for developers performing maintenance or adding discrete features to a large, existing enterprise system. But I am certain it is of no use at all for work that requires discovery, new technology, ingenuity or creative ways to work with difficult constraints. – Jimmy Breck-McKye Aug 9 '16 at 9:21
12

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.

  • Unless you own the company you are given money for generating code. The better code you can produce the better for your employer - thinking in ways to have bargaining chips against your employer is in my opinion not understanding what makes you valuable in the first place. I believe PP is so intensive that you cannot do this all day, but automatically needs resting. – Thorbjørn Ravn Andersen Aug 8 '16 at 2:09
  • 7
    Since some people are forced to make a living from "being valuable to an employer" they also have to calculate with self-interest, and not only with the interests of their employers in mind like minions. – A guest Aug 8 '16 at 3:23
  • 1
    @ThorbjørnRavnAndersen we are not living in an ideal world, where everyone is paying taxes and everyone gets compensated based on merit. – Den Aug 8 '16 at 8:34
  • 1
    @ThorbjørnRavnAndersen The better code the better for my employer? I wish I lived i a world like that, in my world what matters is producing functionality as quick as possible, where code quality is merely an intermediate soft value that should not get any more time than absolutely needed. Bugs are ok, they are usually not severe and easily fixed. – Alex Aug 8 '16 at 10:56
  • @Alex "usually not severe" - I long for that world :D – Gusdor Aug 8 '16 at 12:02
5
  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.

4

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"...
3

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

2

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.