I think this is a fantastic as a 2-3h team activity happening every couple of weeks, if there is a clear feature/bug to be taken care of. Also, great for introducing new team members or non-engineers to the codebase. Doing it full-time does sound weird though.
Mob Programming – The Good, the Bad and the Great
61–70 of 98 posts
Re: Mob Programming – The Good, the Bad and the Great
#62Jesus fucking nope. This is a good approach for some problems, and it may work for this team, for now, but I doubt that this is either sustainable or scalable.
This.
I've done mob programming a lot and it always seems to break down into either a few developers working while explaining what they are doing to others or a developer just typing what other devs tell them to type.
It does work well for knowledge sharing, but that is about it, IMO.
Also, its biggest proponents (where I worked) always seamed to be the devs who didn't actually do anything and had no real desire but learn. I'm guessing it is easier to sit in the back of the mob then fake work somewhere else. Always seemed to have a meeting when there turn got close.
Re: Mob Programming – The Good, the Bad and the Great
#63Upvoting 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 believe another reason to not pointing out the flaws come from mob thinking. It becomes very hard to criticize "the collective". And yes, I think you have a great point on Biggest personality wins, that is already a problem on meetings. Lot's of amazing developers I've worked with had a hard time speaking in meetings...
I agree that the personalities have to be all fairly extroverted for both mob and pair programming. However, as a counterpoint to it becoming hard to criticize "the collective" I've experienced that at least with pair programming the opposite trends to happen. No one had a sense of personal code ownership, so no one gets too attached to a particular implementation or feels personally criticized when criticizing code. My expectation would be that that would happen even less when mob programming. I wonder though what would happen if you had multiple mobs that never rotate team members. I could see that that might quickly escalate to a us vs them situation.
Re: Mob Programming – The Good, the Bad and the Great
#64I 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.
Re: Mob Programming – The Good, the Bad and the Great
#65This 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 anyt…
Oh god, seriously. I can't even stand to see my family or best friends that frequently and for that long, let alone a mob of coworkers (and I love my coworkers). I can see the value of doing this occasionally. But I couldn't spend a significant amount of time in the mob.
Re: Mob Programming – The Good, the Bad and the Great
#66Intriguing concept, but I find a balance of solo work and group collaboration to be the most effective method to accomplish goals. That's why our team invests in weekly or daily (if deadlines make them imperative) reviews of our successes, key updates, and distractions. This forces us to review and reflect on work, receive good feedback, and pushes each member in the right direction.
Re: Mob Programming – The Good, the Bad and the Great
#67"Here’s the crux of it, typing isn’t the bottleneck in software development" This isn't a good argument for mob programming imo. This argument pretends as if the only reason programmers would ever work individually (or in pairs) is because more keys can be mashed in less time. In reality, we work individually (or in pairs) so that work can be completed asynchronously. I can fix a UI defect while Jim fixes a performan…
It's not about sync vs async. It's about performance. People who take up pomodoro-type work tracking are surprised at how hard it is sometimes to get 25 minutes of work done.
I know many people who perform their best when they are training somebody in a system, or are recording training, or doing a webinar. Pair programming evokes the same improvements, and it lasts.
When you're being watched you're more present, and you perform better. I would say that pair programming, assuming no huge personality friction, is more than twice as effective as single programming. There are some companies that only do pair programming, most likely because of this realisation.
Re: Mob Programming – The Good, the Bad and the Great
#68"Here’s the crux of it, typing isn’t the bottleneck in software development" This isn't a good argument for mob programming imo. This argument pretends as if the only reason programmers would ever work individually (or in pairs) is because more keys can be mashed in less time. In reality, we work individually (or in pairs) so that work can be completed asynchronously. I can fix a UI defect while Jim fixes a performan…
[deleted]
Re: Mob Programming – The Good, the Bad and the Great
#69Earlier quoted context omitted.
I wonder if you could set up a round robin programming order. Something like switching which is typing every day. So like whole team puts input while one person types, then delegate one person to drive the discussion. I don't know if that would help much though or just put it back into pair programming with extra overhead.
(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.
Re: Mob Programming – The Good, the Bad and the Great
#70I'm an agile coach and my clients won't stop talking about this. Here's the deal, some 70%+ of developers are introverts. Mobbing can be great for fixing a bug or mentoring more than one person at a time but mobbing is not how you should expect your devs to work all day every day. This is probably not lost on fellow HN'ers but OMG the cargo culting amongst managers. Do not let them see this article. Lastly, watch thi…
Thanks for a balanced perspective.
The fact that someone made a website mobprogramming.org is perhaps the biggest factor that indicts this idea as a silly fad.