Colin, 

To be honest, it is probably difficult to highlight any one event that changed my mind. I guess I would probably say that there was a growing recognition of the complimentary nature of some of the XP style practices and at a certain point they suddenly just seemed to click into place in my head. 

For example, I have in the past, and still do on occasion, say that "if you don't pair program than it is a very good idea to at least do pair design". A pre-requisite for effective pair-design is dividing work into small chunks than can be dealt with (as much as possible) in isolation. 

The next thing is to recognise that TDD done right really *is* design, and done really well is even documentation of a kind. 

This just became, for me, a matter of putting these two things together. Pair design is good, TDD is a good way to design... therefore... Pair TDD. 

If there really was an event that I could probably say finally swung it for me, then I would probably have to say it was when I was working for a particular, well-known .com (I'll 'bid' that you have heard of them), who had different offices in different countries all working on a similar project, the migration of a recently acquired web business on to the Java platform. Naturally there was a bit of competition between the teams, but it was the Germans that really blew the rest of us out of the water. When they were asked to explain the secret of their success they highlighted that TDD and Pair Programming were two of the techniques that had really worked for them. 

Members from the German team were sent to various other offices to do a few sessions on some of the techniques they had been using (unsurprisingly perhaps, they were sent in pairs). 

In one of the sessions they did with us, we projected an IDE up on a big screen, and took a wireless keyboard, there were about 12 of us in the room and we proceeded to develop a little tennis scoring mechanism using TDD. The pattern was that the first person writes a failing test, the next guy makes the test pass, the next guy can choose to either refactor (keeping the tests passing), or write a new test.... and so on. 

Not only was this is a nice little TDD exercise, but what we found was that the most vocal person at any given moment, was the one who was to be *next* with the keyboard. They felt the most ownership over the work being done (more so even that the person doing the typing), because they would be the one most keenly affected by it. They would either have to implement the code to make the test pass, or refactor the code being written. It was actually kind of neat. Our German colleagues, of course, looked on grinning at the sight of revelations happening, and things going exactly as they had planned :). 

My advice is that it is well-worth trying something like this with your team if it is even remotely possible to arrange. 

Someone else on the thread talked about TDD leading to less reusable code. I am not entirely sure that this is true, but I *am* entirely sure that it leads to less, "AbstractGenericJobPerformerThingy", type classes. It is amazing how these can seem like an awesome idea to a single programmer, but much less wonderful when explained out loud. It is *hard* to be disciplined enough to only introduce abstractions like this as they become sensible, and experience often works against us when it comes to this problem. To paraphrase Jeff Goldblum in Jurassic Park, "We are so consumed by the idea that we *can* make such abstractions, we often don't stop to consider whether we *should*". What looks the very model of super abstraction now, is just going to be a head-fuck in 3 months when somebody comes back to work on this stuff. 

This also brings me on to the other subject that gets mentioned, productivity. Bruno has done the maths even :). 'Pairs would have to be twice as productive to make PP worthwhile'. You certainly can look at it this way, but it is not quite right (imo) to define this productivity as 'lines of code per hour' or even sprint velocity. 

I don't know about you guys, but I would say that the majority of my day job is spent reading code, trying to figure out either how it works, or it's conventions so that I can add some new feature or fix a specific bug. My productivity is *directly* linked to the output of previous pieces of development. If the code that has been written before I arrived on the problem is A) simple and elegant, and B) has good, useful tests (which is not always the same thing as high test coverage), then this can turn a 1 day job, into a 1 hour job. Let's call that an 7x productivity gain. 

Now the maths is a bit more complicated, but my experience has been that pair driven TDD certainly does increase the simple/elegant metric, and also the good, useful test metric. Pairing today may well turn a future 1 man-day job, into a future 2 man-hour job (assuming ongoing pairing), and suddenly, there is your productivity gain (and not a small one). 

All this said (and apologise, I realise I have gone on a bit...), I don't do PP everywhere, some places don't support it at management level (and haven't really grasped the 'self-organising teams' thing), sometimes I have team mates that are not really keen, despite my evangelism. I have even worked on some teams that were really dynamic and even solo development felt a lot like, 'team programming' because there was a lot of communication and a real 'collective ownership' feel anyway. 

PP is not a total silver bullet, but I do tend to think that it's benefits are underestimated. Sometimes people don't like it because they have tried it, did it badly and never wanted to do it again. Retrospective meetings also get rejected this one.... one badly run '4 hour bitch-fest with no output', and suddenly it gets unceremoniously dropped from the process, and anyone suggesting it's re-instatement gets told, "We don't do retrospectives.... they suck!". Well.... I would say that even bad sex can suck.... and I will leave you all there, pondering that one... ;)

Wes

On Wed, Jan 30, 2013 at 12:07 PM, Colin Soho Cobra Vipurs <[address removed]> wrote:

Wes (any anyone else really),

Could you share what made you come around to pairing?

On Tue, Jan 29, 2013 at 11:11 AM, Wesley Hall <[address removed]> wrote:

Jim,

Yes, you are terrible!! Please leave the industry immediately! ;).

I was quite surprised to read the part about people not being prepared to stand up and say they don't like pair programming, my experience has been that people tend to be quite vocal about this. I have actually been one of these people.

That said, I have come around quite a bit in recent years. I tend to find that PP works much better if you are also using TDD, since this is a process that tends to lead to quite a lot of 'inner dialogue', even when you are working alone and it is useful to share this.

I think it is important to remember that pair programming is a skill of it's own, it's not just a matter of two programmers sitting at one screen. A singles tennis player is not automatically good at doubles, they still need to train, and people that are good at one thing, tend to get frustrated when they feel less good at a similar thing.

I am still learning. I can get a bit bossy when I am the non-keyboard member, and get twinges of annoyance when I am typing and get reminded to do something that I was just about to do.

On the whole though, I am now quite a vocal supporter of the process. When I come back to code that was developed a while ago and try to understand it, I find a strong correlation between it being understandable and it being pair programmed. I am no longer looking at the historical content of a single person's mind.

All this said, provided you have a good understanding of the kinds of things that pair programming solves, and have another mechanism to solve them. Then there is nothing wrong with having another approach. Personally, I hate doing code reviews, and I often have to pester the original coder to try to figure out what they were thinking, (either, "What were they thinking?" or "WHAT WERE THEY *THINKING*!!!). My experience is that code reviews tend to become very half arsed very quickly. YMMV.

Cheers

Wes

On Tue, Jan 29, 2013 at 9:40 AM, Jim Collins <[address removed]> wrote:

Hi,

I was wondering if there are other programmers out there who feel they are bad programmers because they do not like pair programming.

I feel that I am much more productive working on my own and it is how I enjoy to work. If I am working on something particularly difficult then I will often ask a colleague what they think and when I commit code I also talk my colleagues through what I have done in a code review. That is how I have always worked and how I enjoy working.

I sometimes get the feeling that pair programming is like the emperors new clothes. No one will stand up and say I don't like this so we all continue in this vicious circle :).

Thanks

Jim

--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])

This message was sent by Jim Collins ([address removed]) from LJC - London Java Community.
To learn more about Jim Collins, visit his/her member profile

Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]

--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])

This message was sent by Wesley Hall ([address removed]) from LJC - London Java Community.
To learn more about Wesley Hall, visit his/her member profile

Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]

--
Maybe she awoke to see the roommate's boyfriend swinging from the chandelier wearing a boar's head.

Something which you, I, and everyone else would call "Tuesday", of course.

--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])

This message was sent by Colin Soho Cobra Vipurs ([address removed]) from LJC - London Java Community.
To learn more about Colin Soho Cobra Vipurs, visit his/her member profile

Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]

--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])

This message was sent by Wesley Hall ([address removed]) from LJC - London Java Community.
To learn more about Wesley Hall, visit his/her member profile

Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]