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

21–30 of 98 posts

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

#21

Post by plgs »

tibbon wrote: post #9

I've desire to want to try exactly this. No more 2-week long code reviews, where 2-3 reviewers debate (slowly) over Github about the naming of a local variable. No more drawn out A vs B problem solving. No more 2x a day sync ups. Just put all the stakeholders in a room and crank it out together.

You'd still want to do code reviews after mob/pair programming though, because:

- the whole team might not be here and needs to review the changes to catch up.

- doing the wrong thing as a mob is still doing the wrong thing, and you may need more eyes on your code to spot that (especially if everyone during the session was convinced that what was written is right)

- IMHO, even if 10 persons were involved in writing it, a later review of the code can still improve quality (because people will actually be reading the code rather than writing it, which will expose other kinds of issues)

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

#22

Post by lucasnemeth »

chris_st wrote: post #19
SCdF wrote: post #10

Upvoting because it's a fascinating idea. I find it weird they didn't really point out any down-sides, possibly because it's a corporate blog and marketing wouldn't let them. Off the top of my head though, I'd be worried about: - No time to think. I find I solve solutions by thinking about them, and I can imagine mob rule would lend itself to less thinking and more doing (fastest solution that sounds half-right gets…

> Biggest personality wins. I'd argue that a "big enough" personality (thinking of some past cow-orkers here) cause disruption and difficulty no matter what the situation. Right now we're hiring people with personality type as the foremost criteria. One difficult person is really too many for a small team.

Biggest charismatic personality still wins. You're optimizing too much for extroverts.

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

#23

Post by beat »

I used to use the term "mob programming" to describe a phenomenon I saw at a shop where I used to work. Officially, the process was Extreme Programming, but the physical layout worked for more. There were two "islands" of workstations with five workstations each - two of the largest monitors we could get those days (24"), room for two seats, and spare chairs. Developers each had small private cubes on the outside walls for email, phone calls, and such. Coding work was done at the islands. In theory, it was "pair programming".

What happened in practice was that any number of programmers might be gathered around a workstation, from a single programmer for a straightforward bit of coding, to a half-dozen gathered around for a thorny problem or a coding/discussion session. It was extremely effective!

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

#24

Post by SCdF »

DanielBMarkham wrote: post #13
SCdF wrote: post #10

Upvoting because it's a fascinating idea. I find it weird they didn't really point out any down-sides, possibly because it's a corporate blog and marketing wouldn't let them. Off the top of my head though, I'd be worried about: - No time to think. I find I solve solutions by thinking about them, and I can imagine mob rule would lend itself to less thinking and more doing (fastest solution that sounds half-right gets…

I've participated once or twice and watched mob programming a bunch of times. Here's some feedback, for what it's worth. - Thinking aloud lets you solve problems in parallel, rather than sequentially. But if you're still hung up on something, you're free to be quiet and think, or think later - If it's an ego fight, you've lost no matter how you code. Better to get it out in the open and deal with it. (And perhaps let…

> If it's an ego fight, you've lost no matter how you code. Better to get it out in the open and deal with it. (And perhaps let the person go)

I know what you mean, but "you've lost" is a bit too final for me. Obviously ideally you would never have these people, but in reality you may do, and as that's not the only quality you're judging them on letting them go might be a little harsh.

What I'm talking about is the idea of maybe a quiet developer trying something a little different, and having that good dna making it into the code-base. If you have a group of people who nearly all believe that mocking is a good idea, but someone would like to try refactoring so you don't even _need_ mocking, then I'd worry that in mob programming you'd never have that attempted.

Or perhaps everyone would be really open to that and because everyone is in a group more of those ideas would surface, and more different ideas and approaches would make it into the codebase.

I honestly don't know which of those two situations would occur, and maybe it's up to the team. I'd be really worried about the former, though maybe that says more about my background, who I am and the teams I've worked in though :-/

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

#25

Post by pyrale »

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 to make the right choice for the right situation.

Test code is much more relevant, and it's much more expressive, too.

> - Biggest personality wins. I'd worry that whoever had the largest personality would drive everything, leading to people being disengaged.

Honestly, we didn't run into this problem at all, maybe because it's a dojo setting. Since we're used to mobbing, people will usually be extra careful about it. When there are many people, setting up a fishbowl is a good exercise to teach people to leave more room to others. I've had deadlocks happen during pair programming, but in a mob, it's much rarer. Also faster experiment time leads to much more tries.

> - Constantly bringing people up to speed. Maybe this is actually a good thing?

Definitely a good thing. People asking question is a good predictor of hard-to-maintain code.

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

#26

Post by moridinamael »

lucasnemeth wrote: post #22
chris_st wrote: post #19

Earlier quoted context omitted.

> Biggest personality wins. I'd argue that a "big enough" personality (thinking of some past cow-orkers here) cause disruption and difficulty no matter what the situation. Right now we're hiring people with personality type as the foremost criteria. One difficult person is really too many for a small team.

Biggest charismatic personality still wins. You're optimizing too much for extroverts.

Maybe. Probably. But if the charismatic leader leads the team to five explicit, obvious fuckups in a row, they might learn to shut their mouth for a while.

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

#27

Post by pavel_lishin »

This is an introvert's nightmare. I feel like going to a room and turning off all the lights just reading about this.

I'm glad it seems to be working for them, and I'd be willing to give this a try for a week, but I'm not even sure if I'd wait 'til I had a job lined up before giving my two week notice.

If I have to spend eight+ hours a day doing nothing but talking to people, I'm going to have no energy left for anything else. If I were single and childless, I could maybe manage this for a month, but with a wife and child, the amount of stress would be insurmountable.

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

#28

Post by lotyrin »

plgs wrote: post #21
tibbon wrote: post #9

I've desire to want to try exactly this. No more 2-week long code reviews, where 2-3 reviewers debate (slowly) over Github about the naming of a local variable. No more drawn out A vs B problem solving. No more 2x a day sync ups. Just put all the stakeholders in a room and crank it out together.

You'd still want to do code reviews after mob/pair programming though, because: - the whole team might not be here and needs to review the changes to catch up. - doing the wrong thing as a mob is still doing the wrong thing, and you may need more eyes on your code to spot that (especially if everyone during the session was convinced that what was written is right) - IMHO, even if 10 persons were involved in writing i…

Who reviews, if the mob consists of everyone? If I participated in developing a thing, I would have probably already made the oversight, wouldn't see an issue.

That raises an interesting idea, you split the team, the mob and non-mob, like learning vs testing data. Dedicate some fraction of the team to the mob, then rotate out members. It seems like most of the benefits are realized, if people need skills or compassion for other roles of the project expanded, they get their turn. If the team is large enough that the mob is a minority, you minimize the effect of downsides.

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

#29

Post by lotyrin »

askyourmother wrote: post #16

Mob programming because they don't trust the individual developers to deliver by themselves, mob programming because no one has a clue there and they hope there is wisdom in the crowd, and mob programming because they had nothing else to do.

> individuals don't deliver > no one has a clue

Welcome to Earth.

Most teams are not able to attract or retain talent, so they have to focus on maximizing and concerting effort instead.

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

#30

Post by DanielBMarkham »

SCdF wrote: post #24
DanielBMarkham wrote: post #13

Earlier quoted context omitted.

I've participated once or twice and watched mob programming a bunch of times. Here's some feedback, for what it's worth. - Thinking aloud lets you solve problems in parallel, rather than sequentially. But if you're still hung up on something, you're free to be quiet and think, or think later - If it's an ego fight, you've lost no matter how you code. Better to get it out in the open and deal with it. (And perhaps let…

> If it's an ego fight, you've lost no matter how you code. Better to get it out in the open and deal with it. (And perhaps let the person go) I know what you mean, but "you've lost" is a bit too final for me. Obviously ideally you would never have these people, but in reality you may do, and as that's not the only quality you're judging them on letting them go might be a little harsh. What I'm talking about is the i…

I exaggerated to make a point. Of course you'd work with folks. Apologies for the hyperbole.

You have a good point, but consider this: the team is in the hook for whatever the code is anyway, whether there are disagreements or not. So the real question is whether or not you surface those disagreements (or bury them, in your example), or simply don't address them at all.

I'm thinking you surface them, even if the herd mentality moves in the wrong direction. Unfortunately, unless you can deliver the entire thing on your own, social skills count as much as technical skills. The bigger the team and the more people think "that's not my job", the more the team norming becomes more important than the implementation details.

Or -- to continue with the hyperbole -- if you get it wrong, and you all get it wrong? You did your best. If you do a great job and the team flops? The guy paying the bill isn't going to be so happy with "Yeah, but if they had only listened to me...." Your job is to make the team/project succeed, not be the best coder.

Mobbing is still in the hype cycle. I remain wary, but cautiously enthusiastic. It'll probably be another 2-3 years before all the warts come out.

Post reply on HN