5 ms·
I spent the first fifteen months of my current job on a 100% pair programming team before transferring to a more traditional scrum-based team. Some observation
by dhosek 7y ago
I spent the first fifteen months of my current job on a 100% pair programming team before transferring to a more traditional scrum-based team.
Some observations: team cohesion on the pp team was much higher, code quality was higher. Flexibility, not surprisingly was lower: we had a very fixed schedule: "Stand up" at 8.06 (despite the name, it was unrelated to the scrum event, instead it was more time for sharing news and interesting things before the workday started), team stand up immediately following (this was closer but not quite the same as the scrum stand up), then breaking into pairs and working until noon, then an hour for lunch, then working 1-4 then an hour for individual work like training, administrative junk etc. Remote work was not typical although there were two or three remote team members who lived elsewhere and tele-paired three weeks out of four.
I'm hard of hearing so this was a somewhat draining experience for me thus my switch to my current team. Here, team members typically work remotely 1–2 days per week (largely a consequence of corporate policies which have fewer desks than employees). Each team has 2–3 offshore teams that we work with. It seems like we spend an inordinate amount of time in meetings (my calendar has 11 hours blocked off for meetings in a "normal" week and more is not uncommon). There's a tendency for information to only be passed on orally which isn't great with my hearing loss.
It's not strictly a comparison of PP vs non-PP but overall, I would return to the PP team without hesitation.
- swagtricker 7y agoAgreed. This has been my experience as well. I've mostly pair programmed over the last 15 years. Very similar schedule. Same pros & cons. There's a counter intuitive key element to Pair Programming - you're slowing down in order to go faster. You make fewer mistakes and correct them an order of magnitude faster when you do. You spend less time "thrashing" on something. You're less likely to loose the better part of an hour going down an implementation rabbit hole. Once you let get of the illusion that you can be better long term "by just going off and cranking this out on my own" (e.g. cowboy coding / hacking / JANGIT - Just Add New Garbage Ignore Testing), then the value of pairing really shines. 18 months into a project, you're looking at something that is still high quality, still manageable, and you still actually want to work on because you're proud of what you and your team have done.
- wolco 7y agoDoes one person doing more than the other? Do you literally sit side by side all day? What is your male/female ratio?
- ggregoire 7y agoOther than "code quality was higher", I don't see anything else directly related to pair programming in your observations. Seems more about team culture and organization.
- dhosek 7y agoFair observation. I think, though, that the culture and the PP were closely intertwined with the two feeding each other.
- downerending 7y agoI have some hearing loss as well, and this clearly would kill it for me, even if I thought it was a good idea otherwise. I actually walked through the programming floor of what might be the largest pair-programming operation in the US and was shocked to see (and hear!) that it was concrete floors and ceilings with no sound treatment. Awful. My suspicion is that the jawboning about pair programming has more to do with the fact that it's a legal way to weed out older programmers than for any real economic benefits. We're more likely to have hearing loss, and will seem like poorer programmers in a pairing situation. Plus, we're overall less likely to put up with trendy bullshit like PP.
- jdlshore 7y agoPair programming was introduced with XP over 20 years ago. I think your perception of what’s trendy is miscalibrated.
- riffraff 7y agoIs PP "trendy"? The "extreme programming explained" book that (afaik) popularized it came out more than 20 years ago.
- downerending 7y agoIt was trendy then, and it's trendy now. It's a recurring fashion. Penetration in the real world is almost zero, and for good reason.
- zizee 7y agoThese two points: > Here, team members typically work remotely 1–2 days per week... > Each team has 2–3 offshore teams that we work with Does not sit well with this point: > There's a tendency for information to only be passed on orally I have found a key part of successfully working in a distributed team is overcommunication via some persistent medium. Perhaps you can be an agent of change to improve this aspect of your new team, both for your own sake and the team's. Good luck!
- bborud 7y agoQuick question: how many years of experience do you have and how many different projects longer than 6 months have you been on? The reason I ask is that the effectiveness of pair programming seems to depend on a lot of factors. Including the above mentioned factors.
- dhosek 7y ago>20 years and more than I csn count off the top of my head.