Mark Needham

Thoughts on Software Development

Pair Programming/Helping/Working Collaboratively

with 5 comments

Dan North has been presenting his ‘Pimp my architecture‘ talk again at QCon San Francisco this week and after reading the hugely positive feedback on Twitter I decided to watch some of it again.

The idea of getting people to help each other rather than pair program is what stood out for me this time, something which Brian Guthrie also pointed out:

“We didn’t do pairing, we did ‘helping’. You can’t get alpha progs to ‘pair’ but they’ll tell you what they know.”

It’s been quite common at the places that I’ve worked at for pair programming to be frowned upon and sometimes that’s not the most important battle to fight so the team will be more selective about its use.

I was discussing this with some colleagues this week and it does seem that pair programming is a trigger word/phrase with negative connotations for productivity.

On the other hand, something which is rarely frowned upon is having a team ‘working collaboratively’ and in fact most of the time this is considered a very good thing.

When we work alone I still find myself calling a colleague over to help me out when I get stuck and while I could probably work something out alone given enough time I don’t think that approach makes sense when working on it with someone else leads to us solving the problem much more quickly.

Josh Bloch speaks along similar lines in the interview with him in Coders at Work:

I don’t like working in total isolation. When I’m writing a program and I come to a tricky design decision, I just have to bounce it off someone else. At every place I’ve worked, I’ve had one or more colleagues I could bounce ideas off of. That’s critically important for me; I need that feedback.

I’ve known people who don’t feel this way – who are willing to program in a vacuum. I think it hurts them.

I think it’s fairly inevitable that if a team is to deliver software effectively then there are going to be times when people are working together to solve problems.

What we choose to call that can be varied depending on the context we find ourself in.

Written by Mark Needham

November 22nd, 2009 at 4:43 pm

Posted in Pair Programming

Tagged with

  • Rixt Wiersma

    Remember the metaprograms that are recognized in NLP, for example Towards to -Away from? Your blog reminds me of the internal reference – external reference metaprogram. I guess coders with a strong internal reference wouldn’t mind working alone and even when confronted with a design decision would be okay with coming up with a choice themselves, whereas an externally referenced person, would want to getas much input as possible before making the decision.

  • http://www.theagileconsortium.com Dave Rooney

    I understand the reluctance of people to pair right from the start, but I wonder how much time could have been saved by pairing immediately rather than waiting to ask for help once you were stuck or had a design decision to be made.

    My experience has always (and I mean always) been that pairing significantly reduces the latency between when I need help and when I’m conscious of needing help. Pairing forces me to think out loud, which can quite often make the answer to a decision obvious.

    Dave Rooney
    The Agile Consortium

  • msuarz

    I don’t like the helping alternative. It kills the balance of a pairing session. The alpha whatever a**holes would always be doing the helping because they r too good to need help. The rest of us would struggle harder with problems before asking for help. Because pride is a very human thing.

    All in all the alpha-morons (i really disdain this alpha concept) would still build code that is clever in the best case. Most often what they do is write this super optimal scalable mambo jumbo that eventually becomes a framework an slave the betta programmer that simply don’t get its awesomeness.

    So its natural to have different levels of knowledge distributed in the team. But if the alpha technical ppl are delta capable of working with others there’s a problem. And solving it via the “helping” paradigm just keeps feeding the egos of this alpha nerds.

    Pairing is not about getting help, its about thinking through problems together (and having fun while at it).

    cheers
    mike

  • Andy Marks

    If alpha progs are above pairing, then I assume they’re similarly opposed to reviews of their code… and what about testing of their code? Surely that’s a no-no as it presumes there will be defects :-)

  • http://awkwardcoder.blogspot.com/ Awkward Coder

    IMO once you accept you don’t know everything and you don’t take the lead when pairing (sometimes), it becomes fun and very productive.

    The abilities to solve particular problems are rarely equally matched in pairs IMO. It’s enjoyable being able to sit back and be a sounding board for ideas…