back to article The perils of pair programming

head shot of Matt Stephens smiling The streets of London are busy, especially at lunchtime. Strolling along dodging the slow-moving pedestrians occasionally makes me wonder: how do these people ever get anywhere? And how do they cope with the glacial slowness of taking all day just to reach the far street corner, without their …


This topic is closed for new posts.
  1. Michael Joyce

    Matt misses the point

    The argument Matt gives against pair programming doesn't mention three of the key benefits for pair programming, knowledge sharing, continuous code reviews, and discipline.

    Knowledge sharing in terms of learning more about different parts of an application, this is further enhanced by promiscuous pairing where you only stay together for a story/requirement/use case I have paired with people at all levels from junior to architect. I have certainly contributed in different ways in each pairing, but we have always both contributed and I have seldom felt that it was a waste of time. If there is someone on the team who wont pair they dont belong on the team. Everyone has to play be the rules.

    Code reviews in terms of ... well kind of obvious really, you are having two pairs of eyes always looking at the current code, and next time you get another pair working in that area you get two more pairs looking.

    Discipline in the form of not being able to get away with writing that test after you finish, or i'll just put a small fix in here where I should really refactor this code.

    This is not the same as the beneficial 'do the simplest thing that could work' (pairing helps prevent complex minds infecting code). Simple good, simplistic bad.

  2. Bob Hannent

    Working pair

    Once upon a time I used to work for my brother, I did this while in college and it gave me a good little second income. At the time I would think it was fair to say he was a good to advanced level programmer and I was an average to good programmer. He has since gone on to great things and I wish him continued success.

    I have never really been a coder and yet I have always had insight, I can think my way round almost anything and I can see an engineering solution to most problems. Thus I went on after college to have a career away from computing and I am enjoying a measure of success.

    However, when we worked together I did enjoy myself, not so much when I had an individual commission, but when we would actually pair programme. I believe that each of us was able to look out for the other and we produced code that worked first time because there was an independent debug process going on the fly. If one of us forgot to declare something or if the flow wasn't going to work then it would be seen.

    This was of course a hayday, and I don't advocate that everyone should code with their siblings. But it was some of the most interesting coding I have done without needing to be the most challenging. On the off-chance that he is reading this I will say thanks for the experience and the compliments made by him.


  3. Julian Higman

    Repetition of common misconceptions

    It's a common misconception that pair programming is only about programming (probably it's badly named). It actually combines lots of activities that have been found to produce better code - refining requirements, discussing implementations, reviewing code, extending the test coverage.

    Even the most experienced programmers can find new ways to look at problems, and spot problems or blind alleys that they might have missed working by themselves. Pairing with a more junior programmer isn't about dragging someone else along on your coat tails, it's about having an open discussion about the problem that you're solving. And even the most junior programmers can ask questions that make you reassess the implementation that you first thought of.

    But these are the things that you only find out if you actually try it.

  4. Brennan Young

    Basic cybernetic principle: Tolerance across interfaces

    My father used to work in Switzerland on those fancy high-end mechanical watches they are so expert at making.

    His boss would always stress to him the importance of 'tolerance' within a system. No, this doesn't have anything to do with accepting foreigners in the workplace (although the metaphor can indeed be stretched that far if you abstract far enough).

    Cybernetic 'tolerance' suggests that in any interface between two components (mechanical, digital or biological), 'Component A' must match 'Component B' in terms of quality. Two enmeshed cog wheels should be made of the same grade of brass or the same grade of plastic (or whatever) otherwise there will be trouble. The lower grade component will wear out faster than the other, and probably compromise the higher grade component by dropping gunk and swarf into its delicate parts.

    It matters less whether a high grade or a low grade material is used. What's important is that the quality matches across the interface. The result is that both components are balanced in terms of performance and wear. In a 'pair programming' system, both parties will contribute matching amounts of effort and require breaks at about the same time, so balancing each other.

    So... congratulations Matt Stephens, you have exposed a design flaw in the 'pair-programming' idea, at least as far as cybernetic efficiency is concerned. (Really, it's a gap in the specification, which leads to a flaw, rather than a flaw in pair-programming as such).

    The advantages of mentoring (as you mention) are still valid, however.

    The problem you raise is more of management: If a manager thinks he can get mentoring of junior staff AND the efficiency of pair-programming for the same price, he is misleading everyone, especially himself.

  5. Tom Hobbs

    Depends on your day job

    Most* programmers don't work on really interesting, exciting and clever things. Most* spend their time in banks and large enterprisey corporations "doing IT". In these situations pair programming works because the emphasis is (or should be) on quality, reliability and maintainability. Even if it takes a pair longer to implement some method than a lone hotshot Rockstar programmer, these benefits remains.

    There appears to be some kind of snobbery among programmers** who consider themselves to be faster/better/more efficient/more clever then other developers. Their attitude (at least as I have experienced) is "Why should I share with you?" They miss the point that they're employed to write code that is quality and can be maintained by a _team_.

    In some cases, e.g. contractors, the focus may instead just be "implement this as fast as you possibly can" in which case pair programming isn't the way to go.

    Obviously intelligent decisions need to be made between "need it now" and "need it good". But to throw out pair programming just because "I can do it faster on my own" is just plain daft.

    As an aside; Brennan's cybernetic principle is actually an argument FOR pair programming. Yes, if you have a plastic gear and a metal gear after time the plastic will start to degrade and get stuck to the teeth of the metal gear. But if the Senior Developer is modelled in plastic and the Junior is modelled in metal then you're effectivily saying that knowledge and (hopefully good) habits have been passed down the chain of experience. The analogy now fails because the Senior Developer still has those good habits and knowledge, whereas the plastic gear now has no teeth.

    * I don't actually have any figures to back this number up, but it feels right.

    ** Note the difference between "programmer" and "developer"

  6. Edward Milne

    think Matt doesnt quite grasp the concept.

    Just spent a morning pair programming, been the most productive morning I've had in ages. My colleague had to explain to me what was going on with some of his code which in itself helped him. A side effect of this was that the code was simultaneously reviewed by us both.

    Reading Matts article he uses the analogy of walking down a busy street and slower people merely getting in your way.

    Well how did Matt get so quick in the first place? He'll probably say something like he was born a natrually gifted programmer. The reality is more like he did what the rest of us do and talk to like minded people, compare code, get advice and tinker, which lets face it, is a large part of pair programming. If all highly expert coders like Matt were not prepared to pair program, how could they ever expect the slower coders to get quicker?.

    The only thing I can say to Matt is - carry on with your current outlook thats fine, but expect the slower pedestrians to continue getting in your way.

  7. Anonymous Coward
    Anonymous Coward

    Wonderful observations

    Non-compulsary pair-programming is best called collaboration and it is wonderful. Compulsary pair-programming is best called a chain gang and it is dreadful.

    I share the author's opinion that the best programming is a solitary activity done in sane surroundings. I first read about pair-programming (long before it was called that) being done at Plauger's compiler company and thought it dreadful then. I do believe that programmers must have others (informally) review their work but that is another matter.

  8. Toby

    Another view on Pair Programming

    First of all, I have just ordered your book and I'm sure it will be an interesting read. I'd like to comment on what you're written here,

    There does need to be a back lash against extreme programming, like any fad its only after people have used it and evaluated it, is it fully understood.

    Extreme programming isn't a magic bullet, it is however a very powerful tool if you use it correctly in the right way. To put this into perspective,

    I have worked for three years now for a development house which has adopted extreme programming whole-sale so I have quite a bit of experience in the methodology.

    As this is an article on pair programming I'll stick to that subject not other interesting topics such as when Extreme Programming should be used, after all XP is a

    methodology, and like all methodologies there are times when you would or won't want to use XP. For example, you'd never use XP on safety critical systems as it lacks rigor

    but you certainly would use it for proof of concept projects.

    At our Company we only use Pair programming about 50% of the time. I think this is weakness in your article, any agile method should only be used pragmatically, when it is

    going to deliver benefit. Obviously there are occasions when certain pairs or the task itself are not suitable for pair programming. So buy another computer and do it on your

    own. There is little point pair programming when the work is very simple and has been done many times before. Performing simple tasks would be your analogy of walking

    across town. If the task was to navigate a car across London, then a second map literate pair would be very useful.

    Pair programming should be used whenever the task is new, complicated or different, developers may know roughly how to solve it, what design patterns they are

    going to use but don't know how its going to hang together. Here developers are implementing designs while they code and this is a very dangerous time. Bad designs produce so many headaches further down

    the line, the concept of one developer thinking strategically and one thinking tactically is really true.

    When you get onto true 'Voyage of Discovery' projects, then you're into the land of code Spikes. but we're talking pair programming now so I'll stay focussed.

    Your hypothetical pairings miss out one very important scenario Expert-Expert. All our best, core code has been built with two of our experts programming together. Two experts together make very few

    substantial mistakes and have the ability to design on the fly very elegant pattern oriented code even for 'Voyage of Discovery' category problems. The time saving for architecting that stuff right

    is massive, the result is not only code that works, but code that is simple.

    Everyone has mentioned it, but learning is critically important too. But interestingly its not just junior staff who needs to learn, its all your developers. By far the most damaging code changes we

    have in our company is when one of our bright sparks goes off and rewrites a piece of our core code, then goes off for a week to meetings and customer sites and everyone is left with a major piece of application functionality

    they need to learn how to use by looking at the code. (the darker side of refactoring) This isn't as efficient as the task being pair programmed and then its more likely an authority on that new piece of functionality will be around.

    The statement that you think one indicator of good developers is that they want to work alone is interesting, IT projects now are larger than any single person, you need a strong, direct, efficient mechanism for

    developers to communicate, if not pair programming then what? Of course, other modalities exist but there needs to be something.

    One interesting thing Martin Fowler wrote a long time ago, to paraphrase: "I'm a good programmer with great habits". Habits is one thing you can instill into junior developers quickly (with the aid of a heavy stick, hehe)

    Any process will take a while to teach people to be better developers, but pair programming quickly teaches people the process better developers use to develop (unit tests, refactoring, design patterns, etc).

    As for recruiting Pair programmers, we use Pair programming as part of our interview process, we give people a task during the interview and they sit with our people and write a little code. We haven't had any problems

    recruiting developers who want to do pair programming because most people are looking for the chance to do XP (because its sexy... or as sexy as IT gets) and most people want to code better.

    Toby Sucharov

    Pair Programmer (currently sat on my own)


  9. Matt Stephens

    Thought-provoking feedback

    Thanks for all the feedback, it's definitely food for thought.

    I'm in agreement that pair programming can be highly beneficial for knowledge sharing, continuous code reviews, that sort of thing; with the caveat that the pairs are actually suited to constant pair programming (not all programmers are; but that doesn't make them bad programmers).

    But pair programming appears to have a law of diminishing returns if it's done ALL the time (not counting XP spikes which tend to be solo-coded anyway, of course). The alternative to constant pair programming doesn't have to be (and really shouldn't be) "constant solo programming". Some hands-on team leading, regular design discussions around the whiteboard, occasional pair programming, shared (and continually updated) domain model, project wiki, mentoring junior coders etc, can work wonders for knowledge sharing and code quality, without the added overhead of two programmers working on one program (I know I'll regret mentioning that!).

    (Quick note on mentoring junior coders: not ALL the time, obviously. At some point they'll benefit from cutting the apron strings, heading out into the scary world of solo coding, thinking for themselves, learning without a "security blanket" there to tell them it's okay. Mentoring==good, mollycoddling==bad).

    Naturally, if you work in a pair programming team and you enjoy it, best of luck to you: don't change what isn't broken. It just isn't for everyone or for every situation.

  10. doug rosenberg

    just a cog in the machine, grinding away

    As Matt's co-author on 3 books now, I feel compelled to add a response on this one, especially as it was the pair programming discussion in his "Case Against XP" article that caused us to start writing books together (more on this below).

    I thought the comment about gears in a Swiss watch was it seems to me that having personal preferences and choice is one of the major differences between humans (or humanoid components of a biological system) and mechanical gears, who, I presume, don't much care which gear they are paired with, or whether they are paired at all. Neither Matt nor I are against VOLUNTARY pair programming, and we happily acknowledge that there can be benefits to this practice. What we are both against is MANDATORY pair programming, and "software processes" whose success depends on this practice. In other words, if you (and your friend) like to pair program, then we have no objection to your doing it. But if Matt, or myself, or the guy at the next desk have found that we work more productively solo, don't impose your preferences on us, please.

    I spent 15 years of my career writing code for a living (lots of it on trivially simple stuff like VLSI design automation and submicron electron-beam lithography) and I worked with some good programmers, some bad programmers, and occasionally some bad-tempered but brilliant programmers (one who was hypoglycemic and had a propensity for shouting when his blood sugar dropped, which was about every 30 minutes). I would have gone absolutely crazy (and quit) if pair-programming had been forcibly inflicted on me.

    Matt and I became friends and co-authors (we pair-author our books via EMAIL between London and Los Angeles) because of one sentence in his discussion of this exact topic in the article I mentioned above. I'll cite the line because I thought (and still think) it was brilliant:

    (Referring to the argument that if you haven't done pair programming you're not qualified to comment on it) Matt said: "Luckily, we humans have pre-cognitive dissonance" (I said..."what???") and he continued "I've never dipped my head in a bucket of sh**, but I know, unequivocally and without question that I wouldn't like it if I did". After I picked myself up off the floor and wiped the tears of laughter from my eyes I sent Matt an email and the rest is history. Later he told me that he had almost pulled the line from the article. Good thing he left it in.

    Doug Rosenberg

  11. Marco Bizzarri

    Did you really read the book you're talking about?

    Perhaps I misunderstood your comments, but it looks like you just didn't read the book you're talking about (Pair Programming Illuminated).

    Just three points:

    1) PPI explicity states that you can have people who are not good at PP, to the point that you will have to design your development facilities to accodate them (for example, providing screen from noises from pairs);

    2) the authors of PPI do not measure the experience of programmers in terms of years, as you implies; they measure it in terms of actual experience on the project they are working on; so, you can be an expert in terms of database programming, and a novice in terms of GUI programming;

    3) you state "Not everyone is naturally extroverted or a social butterfly that will wither away if he doesn't get to chatter to his colleagues for eight hours a day."; pair programming, as the authors point, can be quite different according to the types of programmers (extrovert/extrover, introvert/introvert, etc.).

    Am I missing something?

  12. Matt Stephens

    re: Did you really read the book you're talking about?


    I guess you need to keep in mind that the article isn't a critique of PPI; nowhere do I say that I disagree with all the points made in the book -- therefore it shouldn't be too shocking if I agree with them from time to time. :)

    One of the good things about PPI is that it discusses the problems associated with pair programming; but they're still problems.

    Your comment in point 2) is a fair comment; I oversimplified the case on that one.

    Thanks for the feedback,


  13. John Miles

    Methodolgy or Religion

    Why does IT /software seem to attract so many “religions”?

    Extreme Programming is only a methodology and like all methodologies it has strengths and weaknesses. If you don’t understand the limitations of the methodology, then you will fail to spot where you should start parting company with it to avoid problems and disasters similarly if the manger pushes working practices not suitable for the staff they have – too many such disasters and we’ll be looking for yet another methodology.

  14. Shaun Roe

    Books and sh**


    (Referring to the argument that if you haven't done pair programming you're not qualified to comment on it) Matt said: "Luckily, we humans have pre-cognitive dissonance" (I said..."what???") and he continued "I've never dipped my head in a bucket of sh**, but I know, unequivocally and without question that I wouldn't like it if I did".


    True. But if your going to write 390 pages about it rather than that one line, it might be a good idea if you did actually go and stick your head in a bucket of sh**.

    I'm about to read this book, having ordered it from our library, but if you are really telling me that the principle author has no personal experience of the methodology he is criticising in detail, I'll take a generous pinch of salt with it

  15. Matt Stephens

    re: Books and sh**

    Doug was referring to an article that I wrote back in 2001. The quote was concerned with a tendency in XP culture (at the time) to rebut criticism of the process by saying "Have you even tried it?" A bit like saying "How can you possibly say that jumping off a cliff is bad if you haven't tried it?"

    For the record, it was a couple of years after the article appeared when we wrote the book. Like most developers, though, I've pair programmed on & off throughout my career (both in agile and not-so-agile projects), as the occasion calls for it.

  16. manasclerk

    Maybe Matt and his critics are both right

    Matt makes a good point, just not one that's entirely clear, mostly because he lacks a language to specify what different "sized" programmers would be. Some folks bored everyone because they abstract things too much (too big). Others would drag everyone down in the weeds (too small). As one of my lead developers told me, "It's just as important to keep some people _out_ of the discussion." Heaven knows we have all seen this when some idiot manager gets invited to the team meeting, myself included.

    Wilfred Brown and Elliott Jaques argued years ago that people have different sizes that match the size of work that they are able to do. This is not so much experience as it is one's ability to handle complexity in work. Think of when you say that someone "is working out of his/her league" or that someone "isn't big enough for the job". People who are same "sized" work well together. For managers to really work, they have to be the next size up or they don't add value.

    I found that it was less a matter of personality and more a matter of this "size" thing. If you pair a Stratum 1 developer (in Brown & Jaques's speak) with a Stratum 2 developer, you are asking for trouble. However, if you pair a Stratum 2 with a Stratum 2, pair programming seems to increase performance.

    Most corporate environments shed high developmental arc developers because they are a pain in the ass, so pair programming works well there. Many extremely fast-paced development houses have these same folks, and since everyone is about the same Stratum or in the same developmental arc, pair programming works well here, too.

    So maybe Matt's point is right, as are his critics. It's just that we lack a language to nail down our discussion.

  17. Toby

    Stupid Analogy

    Just to be clear. You say you've done pair programming... have you done XP? your book is about XP, not pair programming. They are very different things.

    Your bucket analogy... Its funny but its just not true, is it?

    Your idea that you don't have to experience something to comment on it is just crazy. Its an argument from Ignorance and a Reduction to Absurdity.

    Let me put it another way: If a child tells you he hates brocolli even though he's never tried it. Should we just accept that and make him something else to eat? Obviously no, you make him try it.

    Your argument is an inexcusable philosophical argument to use for any argument except for extreme corner cases like jumping off cliffs. XP is not an extreme corner case. Your argument is just a childlike response you can use to stay in your comfort zone and not bother to try something which may havbe merits.

    One itinerant teacher I once had said to me:

    "When I'm teaching you, you do it my way. It doesn't matter if you think you know better. Humour me, do it my way. That way if you were right then you've lost nothing. If I was right you've gained something. If you ignore me and keep doing it your way all you will do is stay where you are"

    In short: "Try anything once"

    The argument that people should be allowed to choose whether they pair program or not is pretty weak too. Maybe people should be allowed to choose how many hours they work, after all if they are only productive for 4 hours a day then they might as well only work those hours.

    What about the company's right to choose? Maybe they choose you pair program so that everyone understands the code. Maybe they choose a development methodology that makes sense for their project. Maybe its a lightweight methodology like XP because the project goals match XP. XP enforces pair programming, you're against any methodology that enforces pair programming. Sooooo..... Who gets to choose what you do at work? yourself? or the person who pays the wages?

    You can philosophise as much as you like but if XP makes sense from a business and project point of view then you do it, or you leave. Thats how jobs work.

    Don't get me wrong, there are legitimate criticsms to XP, unfortunately we're missing nearly all of them here in what seems to be a childlike foot stamping.

    Legitimate Criticisms:

    XP is great for describing low level code (at the unit level) but is very weak at delivering the stretegic 'big picture'

    XP relys on interpersonal communications between developers, and this starts to become unwieldly at 20 developers. therefore XP for large projects is problematic

  18. Simon Jones

    Much more importantly

    I'm a bit bored today (a common feeling between Monday and Friday), and there's nothing I like better than reading a bit of 'pair-bashing' when I'm in such a mood.

    But....why is everyone so obsessed with 'productivity', 'speed and quality', 'rock star coding'.. etc etc...?

    Do you actually *want* to be doing this for a living? Really?

    Frankly, unless you are very, very lucky... or very, very puritanical then working as a developer in an IT department is probably not your idea of paradise. (Mine is snoozing in front of the cricket somewhere in the West Indies with a large rum and coke. Why not take a moment and have a think about what yours is...go on... just stare out of the window).

    So, with this in mind and as a self-confessed idler, can I point out some of the many, oft-missed benefits of pairing.

    - You get to have a natter all day long. What could be better than the constant interchange of ideas (reasonable or otherwise) with ones peers? They call conversation an 'art' for good reason. I prefer to share drink my pint in good company, why would I not want to do so at work? And whats more you get to call this 'design'! For some reason you pair-bashers all seem obssessed with 'doing'... give me 'thinking' any day...

    - You get to have a snooze at your desk safe in the knowledge that your pair can cover for you and alert you to possible detection. This, incidentally, also helps satisfy the need for some developers to 'do their own thing'. Fine, I say... you code, I'll have a nap... wake me up when your done (preferably with a cup of tea). Its high time the nap was reclaimed as a worker right!

    - You can work with a hangover. I drink a lot... I love to drink... I occassionally find typing and syntactical thoughts difficult when I'm nursing one of my hangovers. Having a pair allows me to at least do *something* useful... Of course this argument assumes only one drunk at a time. Hmmm...note to self.

    - If you're really lucky you may end up pairing with the most attractive member of the opposite sex on the team. Believe me that makes a for a really pleasant day... In fact, I met my current squeeze on an XP project doing just that... so thanks for the warning Kent, but I disagree... I'm very positive about personal relationships on project...don't fight it, just find a room at lunchtime :)

    - Its a well known fact that two people pairing are more productive than two individuals (ok, contentious, but let it ride)... the good news is that you could be using this added capacity to do less work and more loafing!...

    - If you fancy a good skive then what you really need is a slightly higher estimate for your next story. A good pairer can always provide that nod and grim face of affirmation that is so valuable when explaining the additional effort to the customer.... if possible, sucking teeth at the same time can really add some dramatic impact.

    So stop bashing pairing. It helps make this awful, industrial, wage-slavery more bearable...

    Pairing is your revolutionary duty! Down with the Puritans and coding Rock-Stars!

    (hey, this just took me 20 minutes to write... 20 valuable mintues loafing... and directly attributable to pair programming. I owe Kent a pint)


This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2020