Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pair Programming Economics

wiki.c2.com

Post reply on HN
Print view View original

51–60 of 82 posts

Re: Pair Programming Economics

#51

Post by [deleted] »

gleenn wrote: post #32
kstenerud wrote: post #6

> The underlying assumption is actually, For any two programmers, no matter how good he or she is, if we get them to sit together, the value of their work will be greater than if they sit apart. Yes, an ASSUMPTION. Not proven. Not studied. An assumption. > There's an implicit assumption there that all bugs take the same amount of time to fix. No there isn't. > Now, I'm about to make a crucial assumption: that Alice a…

While it's easy to through around words like anecdata and poke at this article for not having hard data, I simply don't think you'll be satisfied because measuring productivity and value delivered are incredibly hard to quantify. I think this article is wholly reasonable in it's approach as attempting to show with some back-of-the-envelope math and some hand wavy explanation that it is, in fact, possible for the econ…

[deleted]

Re: Pair Programming Economics

#52

Post by dhosek »

ggregoire wrote: post #31
dhosek wrote: post #20

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…

Other 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.

Fair observation. I think, though, that the culture and the PP were closely intertwined with the two feeding each other.

Re: Pair Programming Economics

#53

Post by downerending »

riffraff wrote: post #47
downerending wrote: post #37

Earlier quoted context omitted.

I 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…

Is PP "trendy"? The "extreme programming explained" book that (afaik) popularized it came out more than 20 years ago.

It 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.

Re: Pair Programming Economics

#54

Post by MockObject »

bakedbeanz wrote: post #21

I work at a company that does full-time pair programming whenever possible. There can be drawbacks for sure, but overall, I love it. However, one caveat is that our hiring process places emphasis on finding people that are collaborative and easy to work with as opposed to know-it-all "rockstar" developers. We also do test-driven development, so in addition to the most common pattern (driver / navigator) we sometimes…

These are all very valid benefits, which I've experienced from pair programming as well.

Re: Pair Programming Economics

#56

Post by zizee »

dhosek wrote: post #20

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…

These 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!

Re: Pair Programming Economics

#58

Post by bborud »

dhosek wrote: post #20

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…

Quick 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.

Re: Pair Programming Economics

#59

Post by hcarvalhoalves »

My experience pair (and mob) programming for the past months has been very positive, both with in loco and remote peers (sometimes mixed). New hires feel they get a lot of context faster, and experienced peers feel it improves quality, as it forces code to be understandable.

I believe it's instrumental that the entire team is at peace w/ some working agreements to make it work:

- Splitting work between pilot/guide(s) (otherwise, it turns into a monologue)

- Rotating roles often

- No pressure to stay or having to leave for a while

- Have adequate installations (quiet space, standup desks, large screens, 40"+ displays if possible, ambient sound for remotes to join in the session)

- Naturally leads to egoless programming

Re: Pair Programming Economics

#60

Post by juped »

lotwxyz wrote: post #19

This is a wiki that only serves user-agents that are capable of executing JavaScript. Weird.

The SPA rewrite of wiki was an extremely bizarre move and I'm still not sure why they did it. (For those who aren't aware, this site is the wiki - the original one, and was mindblowing in the 2000s.)
Post reply on HN