11 ms·

Mob Programming – The Good, the Bad and the Great

312 points by traxmaxx 10y ago

dudifordMann 10y ago
Perhaps this is good for feature development, or maintenance, but, what about contracts that deal with wholly new development of a complex system? It seems like you would want to operate in parallel at least for the initial push through the architecture and boilerplate structure. Perhaps I am being disingenuous. I do love the idea of being able to not let the numerous tedious meetings interrupt progress. [edit] Thanks everyone for adjusting my perspective. I am sure junior engineers (and seasoned stubborn ones) would learn a lot with cradle to grave development in such a fashion [/edit]
- ajmurmann 10y ago
  Having spent thousands of hours pair programming I would assume that this is were mob programming is especially valuable. The decisions you make early on are the decisions that everyone on the team will have to deal with. So if you do nothing else as a team this should be it. I actually recently had a client who was lukewarm about pair programming. But they mob programmed on new laying foundation work fit new services. We pair programmed on three new services together at the same time. So much syncing had to happen afterwards that mob programming the foundation would easily have been more efficient and effective.
- wpietri 10y ago
  A former colleague of mine, one for whom I have great respect, is applying mobbing for this right now. So far, they think it's a great way to get and keep everybody on the same page. I'm still skeptical of mob programming, although as somebody who's done a lot of pair programming I'm open to it. But the theory makes sense to me. Early on it's easy to make decisions or fall into habits that cause trouble later. Figuring out some of those initial choices strikes me as the best place to apply a lot of brainpower. Once the architecture is established, I'd expect things would be much easier to parallelize. (But I'd still keep pairing and frequent pair rotation to keep everybody in sync.)
- whorleater 10y ago
  > It seems like you would want to operate in parallel at least for the initial push through the architecture and boilerplate structure. I'd disagree there, if there's a place for mob programming, it's probably here. Given every member of the team will most likely be branching features from a singular foundation, it becomes far more important for every person to have a chance to understand the core completely. This also has the side benefit of reducing friction later on by establishing basic conventions.
fiatmoney 10y ago
I was kind of hoping this would be about calculating loss ratios on protection rackets and coding rigged numbers games.
- erikb 10y ago
  I'm open for all kinds of new things. What are you talking about? I guess it's an investment topic? I really don't understand at all what you are talking about, but I'm curious.
  - somehnreader 10y ago
    mob as in gangsters.
- Stwerner 10y ago
  There's always Analytics Made Skeezy if that's what you're into (http://analyticsmadeskeezy.com/blog/ http://analyticsmadeskeezy.com/blog/)
struppi 10y ago
I have not had the chance yet to use mob programming on a real project. But I have used it when teaching workshops and trainings. And it worked pretty well. The first thing I noticed is that no-one tuned out. When I organized my trainings so that participants do the exercises alone or in pairs, some would just not do them. They might have too much problems to even get started. Or, when pairing with a better developer, just let them do the work. In the mob, paid attention everybody joined the discussion. [1] Also, I think there was a better shared understanding of the examples and the solutions after the mob programming. When working in pairs, I had to monitor 5-8 pairs in parallel and give them hints and explain stuff. With the mob, I could concentrate on one screen and join the discussion all the time. And: Others were helping me out. At one point, a participant said: "I don't want to take the driver seat, I am no programmer, just a manager". Before I could even say something, someone else from the audience said: "Come on, try it. We tell you what to write, and after 10 minutes, we'll change again anyway". So, to recap: I really like mob programming for teaching. I think it could also work well when a team wants to learn something new, has a hard design session or wants to bring new team members up to speed. I even think it could work during day-to-day work, but I have never tried that. [1] Maybe I was just lucky and had a great group when we were duing mob programming. But I doubt that.
- benten10 10y ago
  This is a really good idea: for workshops. I don't know about day-to-day or in a classroom setting though. Whenever I did pair programming in college, one of the partners would often be overpowering in terms of skills and intelligence, and would spend most of the time getting the other up to pace. Which is great, except the laggards would often pretend to understand in fear of being looked upon as stupid. As someone who's been on both side of the dynamics, yeahh, not sure about classroom settings. I would love to attend your workshops though!
tibbon 10y ago
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.
- plgs 10y ago
  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)
  - lotyrin 10y ago
    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.
snsr 10y ago
Jesus 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.
- mohaine 10y ago
  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.
SCdF 10y ago
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 done first). Similarly… - Biggest personality wins. I'd worry that whoever had the largest personality would drive everything, leading to people being disengaged. Especially when it comes to engineering / structural decisions, if that person thinks they know whats best you're not going to have the chance to try something (and maybe fail) and grow as a developer - No personal space. You know, maybe it's because I work from home, but sometimes my fiancee messages me a video of a cat being cute, and I might just take 2 minutes off working to watch it, because I'm a human being and not a sack of watery meat sacrificed to the gestalt. I could imagine it would be very awkward to do anything at work that wasn't explicitly working, which sounds pretty suffocating to me. - Constantly bringing people up to speed. Maybe this is actually a good thing? IDK, but I think if some people are faster than others, or people wander off to make a coffee or whatever, or come in at different times, or leave at different times, you may spend a lot of time going over the same decisions and working through the same problem spaces over and over again. This could be a good thing, or it could be OK that some people know about component X and some know about component Y and there is little overlap. If anyone from Meltwater is reading this I'd be interested to know if you had any problems (these ones or other), because it sounds like-- ignoring the first month-- this plan has no flaws. Which seems hard to believe.
- lucasnemeth 10y ago
  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...
  - retbull 10y ago
    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.
mathgeek 10y ago
The one thing that is never mentioned, and that I'd like to see the difference for, is cost to the business.
perlgeek 10y ago
How big is the mob? I don't think you want to do this 20 or more programmers (the more people you have, the more formalized communication structures you typically need). I could imagine this working with four or five people, and I'd be worth the experiment, but I don't think I'd want to do it all the time.
- obeka 10y ago
  (Author here) The team in this post was six when we started, four now (five if you count our coach who's actually worming himself into the mob now ;) ). I would definitely not do this with 20. Then again I really wouldn't want to work in a team of 20 no matter the method.
askyourmother 10y ago
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.
- lotyrin 10y ago
  > 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.
- id122015 10y ago
  Yes, I upvoted because you mentioned that one of the concept is the wisdom, but I for one am aware of the other concept called 'socialism': you have to be sure that each member of the team passed the entry exam, and you have to be sure that none of the team members become lazy and relies on others to lift the heavy burden, because if everyone avoids the heavy burden, then the 'socialism' collapses.
beat 10y ago
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!
- badthingfactory 10y ago
  I worked on a team that was set up exactly like this. Like you said, it was really effective for some ad-hoc discussion about tricky problems. The knowledge sharing was fantastic and I learned a ton. The major downside was the chaos. If you were the team expert in some domain, you usually had someone asking questions about that domain every 20 minutes. Sometimes programming takes 4 hours of uninterrupted concentration. That work was very difficult to accomplish. A small group of us ended up bringing in laptops and separating from the group multiple (sometimes 5) days a week. We found ourselves having to choose between finishing our own work, or helping other people finish their work.
pyrale 10y ago
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.
- jgh 10y ago
  "dojo"?
  - e12e 10y ago
    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
pavel_lishin 10y ago
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.
- k__ 10y ago
  Totally agree. I switched to working remote full-time just because of people who wanted to talk with me all the time in the office.
- emilong 10y ago
  My first thoughts exactly. I'd be very surprised if there were not at least one introvert on that team (there's an awful lot of us!) and would love to get their perspective. Introversion isn't always obvious. I'm guessing in that situation, I'd seem perfectly fine during the day while I'm there, but totally unable to sleep when I got home because of all the talking swirling in my head.
  - pavel_lishin 10y ago
    Weird, when I'm in that sort of situation all day, I usually feel like doing nothing but going straight to sleep.
- squeaky-clean 10y ago
  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.
- enraged_camel 10y ago
  >>This is an introvert's nightmare. I feel like going to a room and turning off all the lights just reading about this. Wow! That sounds more like social anxiety disorder than introversion. http://www.webmd.com/anxiety-panic/guide/mental-health-social-anxiety-disorder http://www.webmd.com/anxiety-panic/guide/mental-health-socia...
ryanmarsh 10y ago
I'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 this time lapse video of a team mobbing and pay attention to the body language. Who is plugged in, who is checked out, who is talking the most? I think this says it all. https://youtu.be/p_pvslS4gEI https://youtu.be/p_pvslS4gEI
- deleted 10y ago
  [deleted]
- douche 10y ago
  Oh, good lord, that looks awful. I'd be fidgeting around like the guy in the black shirt all day. The worst thing is it would just be exhausting. Having to constantly deal with people for eight hours straight, with no peace and quiet or private space to think would be maddening. I'd rather swing a chainsaw bucking up firewood on a hot day.
  - obeka 10y ago
    (Author here) To be fair, we are very rarely mobbing eight hours a day. Some of us come in earlier, some leave later, and you are always free to step out of the mob and go sit for yourself (even though we have been a bit bad actually doing that). I would say that we are effectively mobbing perhaps five hours each day, and the rest is spent thinking on your own, reading up on stuff, doing your own code experiments (bringing good results back into the mob) and doing all the other stuff you need to do in a day.
- gohrt 10y ago
  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.
- SomeCallMeTim 10y ago
msie 10y ago
I think if you are passionate about a methodology then you'll make it work. To truly measure the efficacy of a methodology you'll need some reasonably unbiased observers from outside the group.
rhapsodic 10y ago
No one is as dumb as all of us.
badthingfactory 10y ago
"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 performance issue, and Sue adds a new feature being requested by a potential client. Having worked on a large team, and being an introvert - mob programming would have been a disaster. We had one or two extroverted personalities on the team, and they would have driven the entire effort while the majority sat and watched. It's really cool that this works for someone. Great teams adapt and find a process that works. However, I would advise leadership at any company doing mob programming to carefully observe the more introverted personalities on the team. They probably won't say anything, but they might be dusting off their resume.
- redrummr 10y ago
  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.
  - badthingfactory 10y ago
    You're making arguments for pair programming which is different than mob programming. Pair programming is fine. I did it for two years. Like everything in software, there are tradeoffs, but I had no major complaints.
- deleted 10y ago
  [deleted]
lawn 10y ago
> 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 like this every minute is precious, and laborious manual procedures that you just buckle down and get done as an individual can no longer be tolerated. I can see this being useful. > Individual weaknesses could be overcome. And individual strengths could disappear. > Interpersonal issues and friction had to be resolved. For me it just seems like they would grow and destroy the team. > Stress levels dropped. As an introvert I can't imagine a more stressful environment. > We became more daring and forward. A fear is that you resist change more and you become less forward. > We became friends. I don't think I would in an environment like this. But anyway, what relevance does becoming friends have with being productive and running a successful business? It's super good not to hate each other but everyone being friends might even be counterproductive. Why oh why did you list 10 positive things but didn't even bother listing the negative aspects? I dunno like this completely destroying your productivity or it being a completely horrible working environment for introverts?
- enraged_camel 10y ago
  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.
  - lawn 10y ago
    Interesting, I haven't thought about it like that. It certainly wasn't my intention.
ElijahLynn 10y ago
This looks superfun, can't wait to find a team to try it with someday.
obeka 10y ago
Hi guys, one of the authors here. Wow, the interest was a lot higher than we expected Since you all have been asking, here's a negative excerpt from an earlier version of this post, which unfortunately got cut before the final draft. I'm starting to feel like we should write a follow up post now, but in the mean time, here's this: "It was not all positive. Finding a smooth way of working took a long time, and we lost team members along the way, presumably at least partly because they did not enjoy this. Personality differences became painfully obvious, and a lot of time was spent talking openly and honestly to each other on how to stop rubbing each other the wrong way. Taking on new people is both easier and harder in this setting. The bonus is that they will come up to speed with the work a lot sooner. The drawback is that you have to redo the personality resolution dance before work will run smoothly again." My take on the introvert/extrovert thing: I'm definitely one of the extroverts on the team (even though I, like introverts, get completely exhausted by too much interaction). I thrive in a communicative environment. We have a pretty fair mix of people on the team, and we've spent some time trying to find the balance of that, leaving room for people to leave the mob when needed etc. We usually do not mob for eight hours a day - reality hits, someone comes in early, someone likes to work late, we attend meetings, we are all parents and sometimes have to work from home, and we try to encourage each other to leave the mob at times. My guess is that we mob approximately 70% of the time. My impression is that our introverts, while finding it tiresome, are a lot more expressive and take up more social space in the group than before. The extroverts have worked hard on stepping back and leaving space. We still have ways to go, but we're getting there. We are just one team in an organization of many teams working on different parts and features of the same system. We do not feel that we need to understand 100% of everything all the time, but our general knowledge has most definitely improved, and rapidly so. We all feel more comfortable around our own components than before.
chrisp_dc 10y ago
@teams that have tried this, Do you find problems with bridging background knowledge across roles? For instance, you have programmers with 5+ years experience reading/writing code. They understand basic data-structures & design patterns through second-nature. Does this create conflict and/or dis-engagement between the programmers & the non-programmers (management, QA, etc)? Typically, I work on teams with scarce technical employees. Most of the team are there offloading work that doesn't require the coding background.
smnscu 10y ago
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.
jlangemeier 10y ago
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.
- Zebra_003 10y ago
  HA HA! Author here. Our team name is "The Borg"
RubyRuby 10y ago
Intriguing 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.
greggman 10y ago
I'm having a hard time seeing this as a win. Maybe I not understanding it. You say 70% of your time is spent this way. Just looking at my own coding there's just sooooooo much busy work. Add this field on that dialog, pass this variable to that other class, write that test, etc ... my point being 5% of my work is thinking about the problem an 95% is typing, testing, iterating. Maybe I'm doing it wrong?
enturn 10y ago
I think the idea from mob programming and pair programming in general is that a single programmer working on a piece of code is a liability. Everyone is prone to making mistakes and taking shortcuts especially when rushing for a deadline or when tired. More people means reduced risk especially if the skill set is diverse. Though if bugs in the code aren't much of an issue (ie fixing it quickly results in no repercussions) then one person should be good enough.
metasean 10y ago
FWIW, I'm getting: uBlock Origin has prevented the following page from loading: http://underthehood.meltwater.com/blog/2016/06/01/mob-programming/ http://underthehood.meltwater.com/blog/2016/06/01/mob-progra... Because of the following filter ||meltwater.com^
quickquicker 10y ago
While it sounds like they made this work for their team, I can't help but be reminded of the Borg..
cdevs 10y ago
We would spend to much time arguing until it's just a one man show at work because one of us believes they know it all.
- cdevs 10y ago
  Annnnddddd you lose out on trash talk #personToMyLeftIsAJerk
landmark3 10y ago
how did they even manage to stay all awake?

312 points by traxmaxx 10y ago

Perhaps this is good for feature development, or maintenance, but, what about contracts that deal with wholly new development of a complex system? It seems like you would want to operate in parallel at least for the initial push through the architecture and boilerplate structure. Perhaps I am being disingenuous. I do love the idea of being able to not let the numerous tedious meetings interrupt progress. [edit] Thanks everyone for adjusting my perspective. I am sure junior engineers (and seasoned stubborn ones) would learn a lot with cradle to grave development in such a fashion [/edit]

ajmurmann 10y ago
Having spent thousands of hours pair programming I would assume that this is were mob programming is especially valuable. The decisions you make early on are the decisions that everyone on the team will have to deal with. So if you do nothing else as a team this should be it. I actually recently had a client who was lukewarm about pair programming. But they mob programmed on new laying foundation work fit new services. We pair programmed on three new services together at the same time. So much syncing had to happen afterwards that mob programming the foundation would easily have been more efficient and effective.
wpietri 10y ago
A former colleague of mine, one for whom I have great respect, is applying mobbing for this right now. So far, they think it's a great way to get and keep everybody on the same page. I'm still skeptical of mob programming, although as somebody who's done a lot of pair programming I'm open to it. But the theory makes sense to me. Early on it's easy to make decisions or fall into habits that cause trouble later. Figuring out some of those initial choices strikes me as the best place to apply a lot of brainpower. Once the architecture is established, I'd expect things would be much easier to parallelize. (But I'd still keep pairing and frequent pair rotation to keep everybody in sync.)
whorleater 10y ago
> It seems like you would want to operate in parallel at least for the initial push through the architecture and boilerplate structure. I'd disagree there, if there's a place for mob programming, it's probably here. Given every member of the team will most likely be branching features from a singular foundation, it becomes far more important for every person to have a chance to understand the core completely. This also has the side benefit of reducing friction later on by establishing basic conventions.

fiatmoney 10y ago

I was kind of hoping this would be about calculating loss ratios on protection rackets and coding rigged numbers games.

erikb 10y ago
I'm open for all kinds of new things. What are you talking about? I guess it's an investment topic? I really don't understand at all what you are talking about, but I'm curious.
- somehnreader 10y ago
  mob as in gangsters.
Stwerner 10y ago
There's always Analytics Made Skeezy if that's what you're into (http://analyticsmadeskeezy.com/blog/ http://analyticsmadeskeezy.com/blog/)

struppi 10y ago

I have not had the chance yet to use mob programming on a real project. But I have used it when teaching workshops and trainings. And it worked pretty well. The first thing I noticed is that no-one tuned out. When I organized my trainings so that participants do the exercises alone or in pairs, some would just not do them. They might have too much problems to even get started. Or, when pairing with a better developer, just let them do the work. In the mob, paid attention everybody joined the discussion. [1] Also, I think there was a better shared understanding of the examples and the solutions after the mob programming. When working in pairs, I had to monitor 5-8 pairs in parallel and give them hints and explain stuff. With the mob, I could concentrate on one screen and join the discussion all the time. And: Others were helping me out. At one point, a participant said: "I don't want to take the driver seat, I am no programmer, just a manager". Before I could even say something, someone else from the audience said: "Come on, try it. We tell you what to write, and after 10 minutes, we'll change again anyway". So, to recap: I really like mob programming for teaching. I think it could also work well when a team wants to learn something new, has a hard design session or wants to bring new team members up to speed. I even think it could work during day-to-day work, but I have never tried that. [1] Maybe I was just lucky and had a great group when we were duing mob programming. But I doubt that.

benten10 10y ago
This is a really good idea: for workshops. I don't know about day-to-day or in a classroom setting though. Whenever I did pair programming in college, one of the partners would often be overpowering in terms of skills and intelligence, and would spend most of the time getting the other up to pace. Which is great, except the laggards would often pretend to understand in fear of being looked upon as stupid. As someone who's been on both side of the dynamics, yeahh, not sure about classroom settings. I would love to attend your workshops though!

tibbon 10y ago

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.

plgs 10y ago
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)
- lotyrin 10y ago
  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.

snsr 10y ago

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

mohaine 10y ago
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.

SCdF 10y ago

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 done first). Similarly… - Biggest personality wins. I'd worry that whoever had the largest personality would drive everything, leading to people being disengaged. Especially when it comes to engineering / structural decisions, if that person thinks they know whats best you're not going to have the chance to try something (and maybe fail) and grow as a developer - No personal space. You know, maybe it's because I work from home, but sometimes my fiancee messages me a video of a cat being cute, and I might just take 2 minutes off working to watch it, because I'm a human being and not a sack of watery meat sacrificed to the gestalt. I could imagine it would be very awkward to do anything at work that wasn't explicitly working, which sounds pretty suffocating to me. - Constantly bringing people up to speed. Maybe this is actually a good thing? IDK, but I think if some people are faster than others, or people wander off to make a coffee or whatever, or come in at different times, or leave at different times, you may spend a lot of time going over the same decisions and working through the same problem spaces over and over again. This could be a good thing, or it could be OK that some people know about component X and some know about component Y and there is little overlap. If anyone from Meltwater is reading this I'd be interested to know if you had any problems (these ones or other), because it sounds like-- ignoring the first month-- this plan has no flaws. Which seems hard to believe.

lucasnemeth 10y ago
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...
- retbull 10y ago
  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.

mathgeek 10y ago

The one thing that is never mentioned, and that I'd like to see the difference for, is cost to the business.

perlgeek 10y ago

How big is the mob? I don't think you want to do this 20 or more programmers (the more people you have, the more formalized communication structures you typically need). I could imagine this working with four or five people, and I'd be worth the experiment, but I don't think I'd want to do it all the time.

obeka 10y ago
(Author here) The team in this post was six when we started, four now (five if you count our coach who's actually worming himself into the mob now ;) ). I would definitely not do this with 20. Then again I really wouldn't want to work in a team of 20 no matter the method.

askyourmother 10y ago

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.

lotyrin 10y ago
> 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.
id122015 10y ago
Yes, I upvoted because you mentioned that one of the concept is the wisdom, but I for one am aware of the other concept called 'socialism': you have to be sure that each member of the team passed the entry exam, and you have to be sure that none of the team members become lazy and relies on others to lift the heavy burden, because if everyone avoids the heavy burden, then the 'socialism' collapses.

beat 10y ago

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!

badthingfactory 10y ago
I worked on a team that was set up exactly like this. Like you said, it was really effective for some ad-hoc discussion about tricky problems. The knowledge sharing was fantastic and I learned a ton. The major downside was the chaos. If you were the team expert in some domain, you usually had someone asking questions about that domain every 20 minutes. Sometimes programming takes 4 hours of uninterrupted concentration. That work was very difficult to accomplish. A small group of us ended up bringing in laptops and separating from the group multiple (sometimes 5) days a week. We found ourselves having to choose between finishing our own work, or helping other people finish their work.

pyrale 10y ago

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.

jgh 10y ago
"dojo"?
- e12e 10y ago
  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

pavel_lishin 10y ago

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.

k__ 10y ago
Totally agree. I switched to working remote full-time just because of people who wanted to talk with me all the time in the office.
emilong 10y ago
My first thoughts exactly. I'd be very surprised if there were not at least one introvert on that team (there's an awful lot of us!) and would love to get their perspective. Introversion isn't always obvious. I'm guessing in that situation, I'd seem perfectly fine during the day while I'm there, but totally unable to sleep when I got home because of all the talking swirling in my head.
- pavel_lishin 10y ago
  Weird, when I'm in that sort of situation all day, I usually feel like doing nothing but going straight to sleep.
squeaky-clean 10y ago
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.
enraged_camel 10y ago
>>This is an introvert's nightmare. I feel like going to a room and turning off all the lights just reading about this. Wow! That sounds more like social anxiety disorder than introversion. http://www.webmd.com/anxiety-panic/guide/mental-health-social-anxiety-disorder http://www.webmd.com/anxiety-panic/guide/mental-health-socia...

ryanmarsh 10y ago

I'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 this time lapse video of a team mobbing and pay attention to the body language. Who is plugged in, who is checked out, who is talking the most? I think this says it all. https://youtu.be/p_pvslS4gEI https://youtu.be/p_pvslS4gEI

deleted 10y ago
[deleted]
douche 10y ago
Oh, good lord, that looks awful. I'd be fidgeting around like the guy in the black shirt all day. The worst thing is it would just be exhausting. Having to constantly deal with people for eight hours straight, with no peace and quiet or private space to think would be maddening. I'd rather swing a chainsaw bucking up firewood on a hot day.
- obeka 10y ago
  (Author here) To be fair, we are very rarely mobbing eight hours a day. Some of us come in earlier, some leave later, and you are always free to step out of the mob and go sit for yourself (even though we have been a bit bad actually doing that). I would say that we are effectively mobbing perhaps five hours each day, and the rest is spent thinking on your own, reading up on stuff, doing your own code experiments (bringing good results back into the mob) and doing all the other stuff you need to do in a day.
gohrt 10y ago
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.
SomeCallMeTim 10y ago

msie 10y ago

I think if you are passionate about a methodology then you'll make it work. To truly measure the efficacy of a methodology you'll need some reasonably unbiased observers from outside the group.

rhapsodic 10y ago

No one is as dumb as all of us.

badthingfactory 10y ago

"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 performance issue, and Sue adds a new feature being requested by a potential client. Having worked on a large team, and being an introvert - mob programming would have been a disaster. We had one or two extroverted personalities on the team, and they would have driven the entire effort while the majority sat and watched. It's really cool that this works for someone. Great teams adapt and find a process that works. However, I would advise leadership at any company doing mob programming to carefully observe the more introverted personalities on the team. They probably won't say anything, but they might be dusting off their resume.

redrummr 10y ago
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.
- badthingfactory 10y ago
  You're making arguments for pair programming which is different than mob programming. Pair programming is fine. I did it for two years. Like everything in software, there are tradeoffs, but I had no major complaints.
deleted 10y ago
[deleted]

lawn 10y ago

> 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 like this every minute is precious, and laborious manual procedures that you just buckle down and get done as an individual can no longer be tolerated. I can see this being useful. > Individual weaknesses could be overcome. And individual strengths could disappear. > Interpersonal issues and friction had to be resolved. For me it just seems like they would grow and destroy the team. > Stress levels dropped. As an introvert I can't imagine a more stressful environment. > We became more daring and forward. A fear is that you resist change more and you become less forward. > We became friends. I don't think I would in an environment like this. But anyway, what relevance does becoming friends have with being productive and running a successful business? It's super good not to hate each other but everyone being friends might even be counterproductive. Why oh why did you list 10 positive things but didn't even bother listing the negative aspects? I dunno like this completely destroying your productivity or it being a completely horrible working environment for introverts?

enraged_camel 10y ago
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.
- lawn 10y ago
  Interesting, I haven't thought about it like that. It certainly wasn't my intention.

ElijahLynn 10y ago

This looks superfun, can't wait to find a team to try it with someday.

obeka 10y ago

Hi guys, one of the authors here. Wow, the interest was a lot higher than we expected Since you all have been asking, here's a negative excerpt from an earlier version of this post, which unfortunately got cut before the final draft. I'm starting to feel like we should write a follow up post now, but in the mean time, here's this: "It was not all positive. Finding a smooth way of working took a long time, and we lost team members along the way, presumably at least partly because they did not enjoy this. Personality differences became painfully obvious, and a lot of time was spent talking openly and honestly to each other on how to stop rubbing each other the wrong way. Taking on new people is both easier and harder in this setting. The bonus is that they will come up to speed with the work a lot sooner. The drawback is that you have to redo the personality resolution dance before work will run smoothly again." My take on the introvert/extrovert thing: I'm definitely one of the extroverts on the team (even though I, like introverts, get completely exhausted by too much interaction). I thrive in a communicative environment. We have a pretty fair mix of people on the team, and we've spent some time trying to find the balance of that, leaving room for people to leave the mob when needed etc. We usually do not mob for eight hours a day - reality hits, someone comes in early, someone likes to work late, we attend meetings, we are all parents and sometimes have to work from home, and we try to encourage each other to leave the mob at times. My guess is that we mob approximately 70% of the time. My impression is that our introverts, while finding it tiresome, are a lot more expressive and take up more social space in the group than before. The extroverts have worked hard on stepping back and leaving space. We still have ways to go, but we're getting there. We are just one team in an organization of many teams working on different parts and features of the same system. We do not feel that we need to understand 100% of everything all the time, but our general knowledge has most definitely improved, and rapidly so. We all feel more comfortable around our own components than before.

chrisp_dc 10y ago

@teams that have tried this, Do you find problems with bridging background knowledge across roles? For instance, you have programmers with 5+ years experience reading/writing code. They understand basic data-structures & design patterns through second-nature. Does this create conflict and/or dis-engagement between the programmers & the non-programmers (management, QA, etc)? Typically, I work on teams with scarce technical employees. Most of the team are there offloading work that doesn't require the coding background.

smnscu 10y ago

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.

jlangemeier 10y ago

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.

Zebra_003 10y ago
HA HA! Author here. Our team name is "The Borg"

RubyRuby 10y ago

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

greggman 10y ago

I'm having a hard time seeing this as a win. Maybe I not understanding it. You say 70% of your time is spent this way. Just looking at my own coding there's just sooooooo much busy work. Add this field on that dialog, pass this variable to that other class, write that test, etc ... my point being 5% of my work is thinking about the problem an 95% is typing, testing, iterating. Maybe I'm doing it wrong?

enturn 10y ago

I think the idea from mob programming and pair programming in general is that a single programmer working on a piece of code is a liability. Everyone is prone to making mistakes and taking shortcuts especially when rushing for a deadline or when tired. More people means reduced risk especially if the skill set is diverse. Though if bugs in the code aren't much of an issue (ie fixing it quickly results in no repercussions) then one person should be good enough.

metasean 10y ago

FWIW, I'm getting: uBlock Origin has prevented the following page from loading: http://underthehood.meltwater.com/blog/2016/06/01/mob-programming/ http://underthehood.meltwater.com/blog/2016/06/01/mob-progra... Because of the following filter ||meltwater.com^

quickquicker 10y ago

While it sounds like they made this work for their team, I can't help but be reminded of the Borg..

cdevs 10y ago

We would spend to much time arguing until it's just a one man show at work because one of us believes they know it all.

cdevs 10y ago
Annnnddddd you lose out on trash talk #personToMyLeftIsAJerk

landmark3 10y ago

how did they even manage to stay all awake?