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

Mob Programming – The Good, the Bad and the Great

underthehood.meltwater.com

Post reply on HN
Print view View original

81–90 of 98 posts

Re: Mob Programming – The Good, the Bad and the Great

#81

Post by e12e »

jgh wrote: post #72
pyrale wrote: post #25

Similar experience here at our dojo. Mob programming is great : we've had people working effectively in languages they don't know. And so we've had product guys sit with us and practically transformed them into programmers, able to fulfill their vision. Issues get identified much faster, and design decisions are quickly discussed and tried. Because we're able to get feedback on why we're developping, it's much easier…

"dojo"?

I assume they have a kickass system for scheduling sessions and visiting instructors. I worry about their technique, though, if the spend their time programming rather than practicing martial arts... /S

Re: Mob Programming – The Good, the Bad and the Great

#82

Post by lawn »

enraged_camel wrote: post #78
lawn wrote: post #45

> Work never stopped. It shouldn't stop anyway. This way just seems like work got a lot more inefficient. > Knowledge sharing increased Sure... But I imagine it's hard to keep track of it all. > The overhead got removed. And a lot more overhead just got added. > Anyone could go to any meeting. Where is the win? Meetings should be targeted problem solving sessions anyway. > Our tooling improved. When working together…

Meta comment: I really hate it when people quote multiple individual sentences and respond to each one separately (usually with a single sentence of their own). It sounds flippant and juvenile.

Interesting, I haven't thought about it like that. It certainly wasn't my intention.

Re: Mob Programming – The Good, the Bad and the Great

#84

Post by obeka »

dwc wrote: post #69
obeka wrote: post #47

Earlier quoted context omitted.

(Author here) We do round robin for keyboard input, but a lot more often than that. We try to switch a couple of times each hour. We do not have a particular person driving the discussion though, I do not see that that would help us in any particular way.

In my limited experience pair programming it usually went like, "How about if we combined these and frobbed before ...aww, let me drive and I'll show you." Who had the keyboard might stay the same for hours, or might switch every 15 minutes, depending.

The person typing should not be driving. It's a bit hard to get to that point and we fail it a lot of times, but as a general rule the person sitting at the keyboard tries not to drive.

Also, if you are not the person currently at the keyboard, you are not allowed to just take over. We used strict time boxes at first to make sure that this didn't happen, these days we are a bit more relaxed since it isn't really an issue anymore.

Re: Mob Programming – The Good, the Bad and the Great

#85

Post by yoz-y »

icefox wrote: post #75
dwc wrote: post #69

Earlier quoted context omitted.

In my limited experience pair programming it usually went like, "How about if we combined these and frobbed before ...aww, let me drive and I'll show you." Who had the keyboard might stay the same for hours, or might switch every 15 minutes, depending.

Or just plug in several usb keyboards and mice into one computer so everyone can type without switching chairs or handing the keyboard over.

From the photos it does look like they did just that.

Re: Mob Programming – The Good, the Bad and the Great

#86

Post by yoz-y »

Zebra_003 wrote: post #54
kabes wrote: post #15

Earlier quoted context omitted.

And maybe the cost? If you pay 5 developers, I wonder how much more (or less) they get done by working individually or by doing this mob programming.

Hey! One of the authors here. I really wish we had hard data on this. But we did not have reliable metrics in place before. I would however argue that there isn't data the other way either ;) But in lack of hard data, I can say what our gut feeling is. We started with mob programming because we felt we had a total inability to deliver anything (lots of half done work), and now we feel like we are delivery frequently…

> we felt we had a total inability to deliver anything (lots of half done work)

While I can sympathise with this, I do believe that this is mainly a problem with management. In order for a group to be productive there needs to be a single mind calling the big shots, in your case you offloaded this responsibility to a mob, usually this is the job of a product lead/project manager.

Re: Mob Programming – The Good, the Bad and the Great

#90

Post by Zebra_003 »

jlangemeier wrote: post #64

I propose that this be codified as Borg Programming. A more amoeba like approach could also be an interesting experiment, allowing for teams to split off and regroup as problems fall into specialty areas, regrouping to handle tests, acceptance, training, etc. For a smaller team this may not be feasible, but for a larger group it could be really interesting.

HA HA! Author here.

Our team name is "The Borg"

Post reply on HN