Two To Tango



  • Pair programming!

    Discuss.



  • I have only tried pair programming once or twice and found that it really did improve productivity. However this was not official pair programming as per Agile but was simply working side by side with my boss. My thoughts about it was that it increased productivity because it eliminated those small breaks that occur when your mind wanders off every now and again (oh look shiny shiny) so you are on the job 100% of the time. Of course working closely with your boss does help you to focus more.



  • It works well with two good programmers. Lots of stupid typos or other mistakes can be caught pretty quickly.

    When I was in college, we were occasionally required to do pair programming. If the other guy sucks, either you end up writing all the code while he just watches or he just types everything you tell him to without providing any input of his own.



  • I've had plenty of experience with the pair programming model, and it is overall much more productive than solo. However, sometimes a developer will get "in the zone" and need some solo time to finish a complex thought without being interrupted by the other.



    The best Pair Programming environment I've ever been in is with teams of 3. Two people pair together at a time, leaving the other room to be "in the zone" or to perform away missions such as requirements clarifications or coffee runs.



  • It came up at work, and one guy was adamant that we start doing it that way. I kept my mouth shut, but internally, I immediately went on the defensive because I basically feel that two people at one screen is fucking annoying and spends 200% resources for 150% productivitiy at best and 75% productivitiy at worst.

    I withheld judgement, though, until I'd thought it through and calmed my knee-jerk.

    I have valid rational objections to PP, but it all basically comes down to me personally disliking being in close company with somneone else for too long. The rule is: if I can feel your body heat, you're too close. Step away. Unless you're a chick and we're in bed. In that case, if I can't feel your body heat, we should probably see other people.

    I often assist people with something, which can be considered small pair sessions, and I keep them as short and efficient as possible, because I prefer being at my own desk, and I also have work to do.

    I find it supremely distracting to have a guy breathing down my neck constantly. It would completely drain me by the end of the day. I really don't like breathing down another guy's neck either and I'm not willing to do that.


    So, now that utterly unsocial me has had his say:

    I'm all for teams of two or three, operating as a 'single programmer'; in fact it's what I'm doing right now with another guy (same guy I mentioned earlier!) on a semi-big project. It's very helpful because we're both good at our jobs, we both know of eachother what we're doing, and there's a lot of communication between us. We're on the same wavelength, so to speak. It's very good, very productive and very social and nice. Good for morale. I like that kind of teamwork.

    So I see the advantages of pair programming, but my main point is that I don't believe they're exclusive to PP, and that PP is textbook red herring.

    The guy I work with now sits halfway down the room, so to get to him I have walk around an island and I'd really prefer it if he'd sit across from me or next to me, so that our pair effect would be stronger.

    Reviewing eachother's code is all fine and dandy, but there's a limit to that: at some point your code is good. Readable. Maintainable. Period. Pair benefit on that aspects then drops to zero. Additionally, I know of my coworkers that they write decent code and I have absolutely no intention of nannying them. I have no intention of being nannied, either. Stop staring at my code and let me write. Yes, I have some small gripes here and there about their code (the guy aligns all his assignments, which I think has precious little effect on legibility, but eh. :care), but I bring it up at lunch, and we talk about it. There is no problem here that needs solving. It's okay.
     

    Summary: there is no lauded advantage of pair programming that can't be done to the exact same degree by putting two good developers next to eachother on separate desks. I'll repeat: I wish the guy I was working on for this project sat at the desk next to me, to shorten communication lines to their optimal length. So I understand where PP is coming from, but to do it all day every day is just fucked and I think only the most ebulliently social of programmers could survive that for prolonged periods of time.



  • @dhromed said:

    Pair programming
    But how will I listen to my metal?

    Seriously though, I don't need pair programming; I need people around me to STFU for more than 5 minutes so I can get in the zone. In fact I need my own office and people to cut me a wide berth when I'm working.



  • @dhromed said:

    Pair programming!

    Discuss.

     

    IMO, Pair Programming can be very effective when one programmer is struggling with getting something to work correctly or a particular task is pretty dauntingly complex. An extra pair of eyes can help a great deal

    Otherwise, I am opposed to banging my head against someone elses to get things done.



  • @dhromed said:

    Pair programming!

    Discuss.

     

    I'm not a developer so a don't do pair or even solo programming.  I do technical consultancy and there are times when we pair up to get something done but it is infrequent and very much on a case-by-case basis.  The times we tend to do it are either during a mundane task where a second pair of eyes is useful or if something's not working and we need another person's take on what's happening.

    We certainly don't pair up to do our normal daily work though.



  • @RTapeLoadingError said:

    I'm not a developer so a don't do pair or even solo programming.  I do technical consultancy and there are times when we pair up to get something done but it is infrequent and very much on a case-by-case basis.  The times we tend to do it are either during a mundane task where a second pair of eyes is useful or if something's not working and we need another person's take on what's happening.

    We certainly don't pair up to do our normal daily work though.

    For cable unplugging/plugging or other such maintenance it's recommended (The Practice of Network and System Administration) that a second NA/SA be present and fully aware of the situation. Both to make sure the plan is followed and to be able to quickly help troubleshoot any issues that arise.


  • Garbage Person

     RISE FROM THE GRAVE!


    Anyway,  I find that my most productive work happens in a PP-like environment. Two people to two computers is still the best way to go about it, but park their asses right next to each other. This makes for excellent division of labor for tasks that can be paralleled (one guy prods the UI, another prods the database, and whoever finishes first prods the data access layer, shit like that) and gives a second set of eyes for actual hard problems.

     It's also my experience that having an extra 10% (one dev per 5 teams) makes a dramatic difference, especially if that extra man is the most experienced. That extra developer is an excellent supervisor (assuming that in addition to being the most experienced, he's also not a prick hung up on 'his way') - feeding and nurturing the teams under his command, delegating to them the work that is the best suited to them, shoulder surfing and giving advice, maintaining documentation (which as a rule should not be more than 10% of his time - I mean really basic essential documentation - architecture diagrams, database diagrams, the kind of information that you stick up on the wall of the office for a quick reference), working as a third developer on a team to get more parallel threads for a critical issue, and giving a third, more experienced set of eyes for really stubborn problem. He's also a great first step for code reviews. 

    Experience shows that with a full team of 11 'paired' developers, you wind up with about 225% productivity versus 11 independent developers (since they're both working on a task, and are depending on each other, they won't tend to facebook the day away - and the extra man prevents them from making a secret facebook pact - unless you make the error of making that extra developer LITERALLY be their boss, instead of being another peer with only informal management abilities) and a large measure of improved code quality. 

    Strict agilista pair programming sucks ass, though. Two heads, one computer? Double the cost for 150% productivity and 125% quality.

     

     I was part of an agile transition once, and several (new, freshly educated) developers were advocating following such and such agile methodology to the letter - it took me getting up in front of everybody and reminding people that the whole fucking point of agile techniques is to be able to target the development team to the crack-addled herd of cats that are business requirements, all the while getting it done faster and better. A particular 'agile vendor' comes up with something that worked once and sells it.You can either take their word for it or play with it - combine it with other techniques, tweak things in ways that sound like they'd make for a better working environment AND more productivity ("Really guys. Do you want to not have a computer to call your own?" works nicely) and if it doesn't work, change the damned process

    So we ended up with a mashup of eXtreme Programming, Scrum, RAD, and dozens of other nauseatingly boring (but edgy-sounding) terminologies for simple, logical ideas that follow from these. And. It. Fucking. WORKED. I could make a bazillion dollars on the Agilista lecture circuit if I cared more about money than I did about enjoying myself.


Log in to reply