Pair programming: The most extreme XP practice? I was an early adopter of XP (Extreme Programming). I read Kent Beck’s book when it was first released in 1999 and though sceptical of some of the ideas, others resonated very strongly with me. I had been using something like Continuous Integration, though we didn’t call it that, in projects from the early 1990s. I was …
Of course the difficulty is finding a peer at/near the same level as you, and also thinks similarly enough that there is little friction, but differently enough that you can challenge each others assumptions.
gut feel based on this experience, when it works it works brilliantly but cant see it working all the time.
This post has been deleted by its author
I've done pair programming, and it works where it works, and it really doesn't work where it doesn't belong.
Given two top programmers, one will be busy writing code, and the other one will be saying, "yep, good..." over and over again.
Given two idiots, you will not get good code no matter how many more idiots you add.
Given a senior programmer and an able novice, it's a great way for the novice to learn. I endorse that highly.
The problem is that it's pair programming, in an open and noisy environment. There's a lot of distraction, which cuts down on productivity. There's the problem that the other guy can't even type.
Pair programming can be good, but it can also be a great way to lose people.
"What about pairing two average programmers, which is the most probable use case?"
Using the same kind of arithmetic used in the financial sector for creating low risk securities, if you combine two averagely competent (or worse) people, and then consider them as a single item, the single item will perform much much much better than the two individual items on their own. What could possibly go wrong?
The main issue with pair programming as currently employed, by Thoughtworks and elsewhere is that it has become a base part of the cult of the extrovert currently rampaging through the industry.
Somewhere between 40 to 50% of people are naturally introverts. This is not the same as 'poor communication skills', and if that's what you believe, you are deluded about the way peoples minds work.
Introvert vs extrovert is an inate quality of a person, and doesn't change through their lifetime to any measurable degree. They may learn behaviours that change their outward, but internally, nothing changed.
So, pair programming, why is this bad?
Extroverts love pair programming because it enriches them, gives them strength.
Introverts find pair programming draining, it saps their mental energy. Simply because they fundamentally find peace in solace, not in social interaction.
Forcing pair programming all the time in a dev team is abusive towards introverts, and you will end up with a team that is made of extroverts after the introverts leave. In the extreme agile teams, this washing out is seen as a good thing, as the introverts aren't wanted. They are seen as inferior because of something innate, their introversion.
So, I'd say, pair programming as a developer discipline is good, I like it. It should not be enforced.
It is also not proven to give all the benefits that it is sold as giving. Groupthink is far too common in this kind of scenario. It may give you more standardisation and some aspects of quality, but it doesn't often give you the kind of extremely creative results that you get by sitting and thinking by yourself.
Brain storming has the same problems. Fundamentally, it doesn't work.
So, in summary. XP is good, pair programming has it's place, don't adopt anything religiously, go for a walk and think for a bit.
Your life as a developer will be that much richer.
The first question I teasingly ask new parents after a couple months is "introvert or extravert?" Often they don't even know what I'm asking. Explaining, it hopefully gets them to think about their treasure as a distinct personality that might differ from their own tendencies.
I sorely miss the opportunities to watch over someone's shoulder as they tackle something they are currently having problems with. Very often, while exploring their difficulty and helping them, I am rewarded with seeing a useful technique or hearing an eye-opening tidbit I've not encountered before. We both get a reward!
But as an introvert I can't mosh with everyone/anyone more than a couple hours a week. I do need the space, the distance, and the quiet, to work. (After hours is when I can relax, yes?) If this becomes labeled antisocial then that will be 'extreme' programming.
Not yet experiencing it full-on, I can still see how useful it might be, in metered measures. After all, command sequence 'xp' is shorthand in Vim for swapping adjacent characters, a very useful trick. Swapping seats working through a conundrum has to help shake out new directions...
Very good point. And a consultancy like Thoughtworks will generally only hire extroverts because their noise and personallities will appear to be greater value for money and more impressive to the IT-ignorant managers who sign off the budgets.
Pair programming with mismatched personalities is a disaster.
I'm just a nerd, so what do I know...
But I do consult in process improvement and while it's not quite "pairing", I am a great proponent of brain-storming. Just three or four smart people bouncing ideas off each other. I've seen some incredible output from these sessions.
So I can see how it could work with pairing.
"I am a great proponent of brain-storming"
Then one of us has perhaps not really understood pair programming.
Brainstorming is a diversion from the normal day to day routine. When I was doing "pair programming" semi-officially, it *was* the normal day to day routine (it helps if you sit adjacent or have an electronic equivalent). As others have noted, PP is very dependent on compatibility, brainstorming less so (especially if a competent moderator makes sure everyone's voice is heard).
The project I was working on simply wouldn't have been delivered without the two of us - with different skill sets, different areas of knowledge, both of which were essential to the end product. Brainstorming as and when wouldn't have been anything like as effective, not least because once you've got an idea, you have to make it work, which pair programming can help with, whereas brainstorming isn't the right tool for making an idea work.
My 2c.
What I am spending as much by doing calculus (or scribbling sketches and schemes, looking up things in books and papers...) as having hands on keyboard? Even brief interruption and loss of focus can easily ruin ten minutes of work. Do you only program things that do not actually require thinking? Or is everyone except me such a genius that he can keep complex mental schemes in his head -- while communicating with other people? I do not understand. Note I mostly develop scientific software (so, yes, calculus is involved regularly) as do most people around me. But they all need to focus to get anything done right.
I'm not qualified to comment on pair programming, but here's a theory about how agile methods increase productivity for rather mundane reasons.
Despite all the waffle about ownership and empowerment, one of the ways in which methods like Scrum improve productivity is simply be exposing every developer's efforts to the team. In a waterfall environment you get a piece of work and a relatively long slice of time to do it. Depending on your outlook, you may get it all done quickly then spend the rest of the time surfing, or spend most of the time surfing then get it all done even more quickly. In agile development, the smaller tasks and reporting to the daily stand-up tend to cut down on the time spent goofing off*.
I wonder if pairing enhances this effect? The two developers are unlikely to conspire to spend part of their time doing nothing much, so their noses stay in contact with the grindstone and the treadmill keeps on turning.
* I wish to make it clear that I personally think the goofing off time is when your brain does its best problem-resolving work. YMMV.
Many programmers see programming as a lone creative process where progress meetings, liaison with the client, preparation of documentation and costing of jobs are not enjoyable and/or productive facets of the project, yet their code is sound.
There are others that are the opposite of that, having the knack of extracting precisely what the client needs from scant discussions with the client, but maybe their code is not so creative.
Pairing these two types together would arguably be the perfect combination, but surely this is the traditional programmer/systems analyst setup? It may help to reduce temptations of writing impenetrable code, and variations to specification due to incorrect interpretation of a client's requirements.
I'm a writer; I live with a writer. We tried writing as a team. It worked well, but we only lasted for six short stories. (They were *good* stories, too. All of them sold to a top market.) But it was a strain.
She tried collaborating with a good friend, and together they produced six novels, one of which was nominated for an Edgar. As time went on, they began screaming at each other. They quit while they were still friends. One took the series, the other started a different series. Both were successful.
It works when it works, but when it doesn't, give up after you've had a decent try..
Long ago, I was a programmer. Fortunately, I never collaborated -- it would have driven me mad. Your mileage may vary.
Your experience mirror's mine over the years; I didn't realise the way I had been working since the 1980's had a 'trendy' name :)
What I found was that paired working works best when skill sets overlap rather than duplicate, this means that the work can be better shared, rather than simply duplicated. Additionally, it is helpful for such pairings to only be 'temporary'. By this, I mean just because a pairing works doesn't mean a pair should simply roll onto the next project and the next, as a 'couple'. I think your example and experience also bears this lesson out. Additionally, your experience bears out the other part of my experience, pairing can be applied more widely than just software development, the only real problem is getting clients to pay for two pairs of hands when they perceive they only need one and hence are only willing to pay for one...
"Long ago, I was a programmer. Fortunately, I never collaborated -- it would have driven me mad. Your mileage may vary."
yeah, good point.
paired programming works ok if "I drive" and the other guy [whom I'm assisting in getting the project back on track, for example] has intimate familiarity with the details. Then I can focus my 'big picture' mentality on getting the solution, and make use of "the detail guy's" experience. [it's worked well a few times, actually]
but for day-to-day development, I wouldn't bother. just use it when it makes sense. it goes in line with the "mythical man month". 2 programmers working on the same thing might be worth 1.8 programmers. Or 10. YMMV.
Hi, Dave Farley,
There are those which/who commit and comment here on El Reg, pairing sublimely and autonomously and anonymously with all manner of beings into all matter of things, and in so doing do they move and remove themselves far beyond any normal comprehension which would tend to hinder rather than promote advanced progression. And once a forward operating base is secured with knowledge unimpeachable and services satisfied, is it easy to pause and ponder and practise a return with journeys to enlighten and lead the masses on the way to go forward, in any number of novel ways.
We didn't call it pair programming simply working together to solve problems.
I was an embedded person and the other half of the pair was a DSP genius. We both knew what each liked and much more importantly what each disliked so the division of work generally happened naturally. Together we could solve almost any problem we encountered and the way we best communicated was simply by talking though not necessarily sitting together for most of the time.
When you're pairing, you aren't sitting on the register or facebook or reading blogs.. You've got 2 people focussed on a problem instead of 2 people half focussed on a problem. But you can't sell it like that because people like not working (even if they love being a developer).
I like procrastinating a bit, I like pairing a bit with the right people. I tend to shy away from pairing most of the time, but this is mostly because it hurts my back sitting next to someone leaning to see a screen together and reaching for a keyboard. We've overcome this in the past by having 2 monitors and 2 keyboards and 2 mice... but it just never really works the same because you're both looking at separate screens you aren't interacting with each other so much.
"If you have never tried pair programming, try it." -- sure.... in your crazy free and easy hippy "work" world eh? SOME of us have actual work to get done, critical deadlines and you're the only one stuck on a project. Even spnding all 24 hours in a day isn't enough, no hope of hiring extra staff to even help you keep sane, let alone for fancy nonsense like this. Get real. Get a job in the real world. Stop espousing these unrealistic hippy ideals. Only when you're in a position where you actually realise that even suggesting nonsense like pair programming is idiocy, have you actually got a job in the real hard world of work
I'm the AC who added the comment "We did pair programming. Now we do mobbing".
My industry does not like us mentioning who we work for but suffice to say we are in the real world (with deadlines), and in fact much of what our organisation deals with involves genuine life and death scenarios. We have ever-decreasing budgets. We have external paying customers. Hippies usually dislike us immensely. We do mobbing. These things are not mutually exclusive.
The fact that your employer has recruitment hangups/issues/budget shortfalls is not actually relevant to the discussion. As your headcount means you can neither do pair programming nor have 2 developers working separately, the question as to which methodology to pursue is redundant.
Where I work, we really kicked in with pair programming and saw the benefits mentioned in the article. We then took it further and now do mobbing.
We have a huge wall-screen, a bank of chairs, a single desktop and 6 developers. We all work together on the code (using TDD) rotating amongst us for who sits at the desk and does the typing. Occasionally (suprisingly rarely) we'll add a task to our story for, maybe, implementing an interface or some such and a pair will split off to a desk, action it and return. Other than that we are one team, one codebase, every day, all day (with a 5 minute break every hour or so).
We are working on the same ever-iterated codebase we were before we introduced pairing. Switching to pairing slowed us a little but boosted our overall throughput due to better code/fewer bugs plus the elimination of peer reviews (as we worked with a peer on the code).
Switching to mobbing was, we expected, going to slow us down. It did, but only if you disregard the quality (oh, you fool). With mobbing there is nowhere to hide; we are all better developers as we've dropped many subconscious bad habits while taking on the best bit of each other's workflow. We have unbelievably less bugs than before, and these are almost always due to domain misunderstandings and (almost) never traditional bugs. Nobody can skip testing (a recent Angular multi-screen form had hundreds of client-side tests alone). Nobody can add quick hacks. Nobody can do workarounds. The team sees all.
The breadth of disparate knowledge and experience amongst us leads to a pool of ideas to choose from at any time, in-depth discussion of pros and cons, and notably fewer false starts or mis-steps. Many dead-end coding avenues we might have gone down on our own or in a pair are dismissed right at the start thanks to consensus, discussion and combined experience.
Prior to pairing, back when we first introduced peer reviews (I hated the idea) there were people I'd never ask because they challenged me too much. Now, all the developers (and quite a few non-developers) in the office can see every line I write and hear every suggestion/justification I make and I wouldn't have it any other way.
I'd be disappointed to 'step back' to pair programming. Devolving all the way back to solo work would be gut-wrenching.
Great idea (and a plus vote.)
I like the idea but I have only one other person in my department (of which I'm the manager and paper-shover.)
Back in my earlier days at very large corps and gov't agencies, this would be welcome. More eyeballs on problems and more chargeable units.
Snideness aside, I'd love to be in this environment - combines the previously-mentioned brainstorming with actual coding/testing/integration in real time. The development (and ops) tools have really matured enough to make this happen now.
"Where I work, we really kicked in with pair programming and saw the benefits mentioned in the article. We then took it further and now do mobbing."
sorry, I see that as the *WORST* outcome of an 'Agile' philosophy, infinite scrums and no work being done, and "the junior guy" has as much influence as the most senior and experienced and competent person in 'the mob', because, "fairness". And predictable lousy outcome.
Also can't help but think of an old silent film with the 'Keystone Cops'.
You're free to see it as you wish. The experience differs though.
Firstly, as I stated the quality/throughput combination increased. We do not spend our time chatting; we actually code. At the same time the combination specifically reduces lousy outcomes by eliminating sloppy solo hacks, stopping untested 'fixes' and ensuring that all developers are quality gate-keepers as a matter of course.
Secondly, the junior does *not* have as much influence. They have the equal right to an opinion and sometimes prevail through specific domain knowledge. Usually, however, the more experienced developers overrule.
Thirdly, the 'juniors' don't stay junior (in ability) for long as they are continuously exposed not just to more experienced developer's code but, via discussion, the actual thought processes behind choices made. That is invaluable and leads to rapid quality parity.
Fourthly, infinite scrums? Where do you get that from? As we work together virtually all the time (occasionally a pair will break off to complete a parallel task), the need for any kind of process-type meeting is virtually eliminated. We still do a daily stand-up so we can include UI/UX guys and customers, but they are invariably short.
I agree with you to the extent that I, too, thought the idea ridiculous. I hated peer reviews and was against pairing let alone mobbing.
Then I tried it.
This is a term that I first heard used by the RAF in 1981 to emphasize the benefit of the two-seater Tornado.
The new RAF aircraft is the Typhoon, which is a single-seater aircraft. Did they change their minds about pair-flying? Do the Typhoon and Tornado fulfil different air-support needs? I don't see any clear yes/no answers to these questions nor the question "Is pair-programming the best approach to producing software"?
I still say that the old term "Different horses for different courses" is you best guide-line.
Happy arguing!
The tornado is a strike aircraft. First designed to perform low level bombing runs over the central european plains, retrofitted with the ability to shoot down other planes.
The Typhoon is designed as a air superiority dogfighter, with a recent addition of an 'austere' strike package.
Very different design ethos and purpose.
No silver bullets here.
"The Typhoon is designed as a air superiority dogfighter, with a recent addition of an 'austere' strike package."
Going a bit off-topic, but the RAF's interest in what became the Typhoon started with the AST.414 requirement, which was intended to replace both Jaguar (another single-seat design) in the mud-moving role and Phantom (a two-seat aircraft) in the air-to-air role. The latter took priority (although the Phantoms were actually replaced by Tornado F3 in the meantime), which is why it took about a decade after entering RAF service for the Typhoon to start receiving some air-to-ground capabilities. And, due to a lack of funding for anything else, it's now also partially taking over from the Tornado GR4 (two-seat) bomber.
What this has got to do with pair programming though, I'm not sure...
The biggest mistake with things like XP/Agile/ etc is that it is a magic formula that managers can apply to any project and suddenly you get results.
Life and the world is not like this. Firstly a lot of these ideas spring from California. You can not assume something that works in one culture will work in others.
Secondly Software is a broad church. You cannot assume that all methods work for all software development.
It's OK to try these things out, but do not feel it is your fault if they fail. In the end any mature team migrates to the best way of working without the use of buzzwords
As the anonymous coward who mentioned mobbing, have a thumbs up.
I offer it as an option that works for us and should not be dismissed lightly. Pairing/mobbing may not suit for some developers (perhaps many) but to denigrate it without just cause (not referring to you hammarbtyp) is just lazy.
Also, your first paragraph. Very true. And unfortunately once that stage is reached it stops being agile in anything but name. How quickly we go from "we value individuals and interactions over processes and tools" to "here's a new agile tool and a process that everyone should follow".
lets both pat each other on the back. it'll feel like we're doing something great!
Dont get me wrong, i generally support pair programming but it works when u have nice people with 'good enough' technical skills. that's most people.
I once had the (dis)pleasure of working with a very capable individual, who was awful to work with. patronising, self agrandising, ego centric, unresponsive. i could go on but i'd run out of pejorative words to describe this person. The irony was that this individual was a pair programming evangelist - yes, he'd introduced our team to the practice but was himself such an arsehole to work with.
i still hold that genuine inspiration comes from those moments of enlightenment creative people experience... on their own. often at 3 in the morning.
Pair Programming is a Silicon Valley concept that is indicative of a wider problem, the base assumption that people are interchangeable. Companies are being created and managed by people who grew up getting participation trophies and always told how good they were regardless of actual performance.
Pair programming assumes that any two people you throw together will work symbiotically. If you're a small company with a selective hiring process, that might be the case. Agile/DevOps in general makes this assumption. As a Team, we're the best! That's the battle cry of the mediocre. If you lack any superstars on your team, your product will be mediocre.
Look at sports for a perfect analogy. All professional sports teams (good or bad) are comprised of professionals who have played the sport for most of their lives, honed their bodies and minds to be the best they can be. But is a team comprised of mediocre players a good team? No. Good teams have good players, and great teams have superstars. Cal Ripken Jr. and Brett Favre didn't set the consecutive starts records because their teams didn't have a capable backup. They set them because they were the best at their positions.
I feel sorry for a team where everyone is truly interchangeable. And I feel worse for the superstars stuck on teams where interchangeability is just assumed. But I'm perfectly aware I live in a fantasy world where people actually strive to achieve a better version of themselves.
I feel some thumbs down coming.
"Companies are being created and managed by people who grew up getting participation trophies and always told how good they were regardless of actual performance."
no argument from me. I'm sure many of these companies are 'Unicorns' and, ahem, "one or two" articles in THIS fine online publication have been rather *scathing* regarding their true value...
worse, though, is (it seems) a lot of the engineers are _ALSO_ "like that". And it's "their turn" now to do things "their way" [explaining Win-10-nic, for example].
so paired programming could ALSO be a pair of IDIOTS circling the drain...
Mobbing guy again ...
I'd agree. We're a small team and our workload covers a wide range of activities (back end code, front end code, databases, servers, DNS, cloud and so on). This means that we can have many 'superstars' as we all have differing abilities in each are. I struggle to see it working with a larger and more even set of skills for the very reasons you mention.
Software is not a sport, if you really must dumb us down, we are somewhere between story tellers (its not real) and lawyers (except when it is).
Pairing is; you write the test, I make it pass, I write the test, you make it pass.
I don't particularly need you next to me to do that, in a lot of ways it's easier to use a shared screen -x session on a server to do pairing.
DevOPS = Firing OPS, make MTTR more important than MTBF.
Ultimately, so long as we are up and making money, we prefer to be available, and we'll settle for eventually consistent.
If the answer to fixing it is "turn it off and turn it back on again" why is that we have OPS?
OPS needs rightly or wrongly a better answer than "I don't fancy being a programmer".
Applications need "monitoring" why doesn't that get built into the applications and services directly.
If it can't be automatically installed, how are we testing it, and if we can automate, build, deploy, test, package, upgrade, and retire stuff on C/I then at what point is it worth having a dividing line between making it work and making it supportable.
We don't have an OPS team, we do have a DevOPS team, staffed by exactly the same people who where in the OPS team, they do mostly the same stuff they did in the OPS team, ie. automate, advice, support, deploy and monitoring.
In a business that has a frightening amount of ego. Take any two people, and one will be the intellectual better of the other. If both can lose their egos (while actually doing the job), I'd hope the standards of both would be raised.
I have actually done pair programming, long before pair programming actually existed (this was 25 years ago). I spent a lot of time working with an AI specialist, while on a sandwich placement. I was learning AI stuff, from her, while also helping here with the nuts and bolts of normal programmy things (translating the none AI stuff - things you'd do in a procedural language - that you actually need to make an application work), in Prolog.
Cubicles are not designed nor equipped to facilitate pair programming, the required workspaces are fundamentally different.
People fart, belch and don't eat enough breathmints. Workspaces generally need more ventilation, in addition to different layouts and equipment.
PP is a tactic that has good reproducible results, yet is nevertheless difficult to implement and scale.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
