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.
- 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.
Not at all the case, we had some bad but felt the post was kind of long so they ended up edit out. No one but us reviewed the post first ;) Actually didn't even really notice all the negatives were gone until it was mentioned...
Here is the negatives we edited:
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.
This was actually a focus of a retrospective today, and we do see this happening sometimes. We agreed today to try to be more aware of it, and for people to speak up when they feel it is happening.
This was only the case for the first few weeks, then as we point out in the article: "Interpersonal issues and friction had to be resolved. When interpersonal issues happened they get brought up much more quickly. In a ”normal team” when there are these types of interpersonal issues they are often allowed to fester. People who have issues only need to deal with each other for limited periods of time, so they just grin and bear it. This isn’t really possible inside of the mob because you would go completely insane."
So this ended up being actually the opposite effect in the long term, dominant personalities were addressed and we all grew as a result.
This is indeed something we struggle with, and we bring it up a lot. People are allowed to leave the mob as often as they choose, but sometimes it feels like there is a social pressure to stay. All I can say is we try to be aware of it, and one of our working agreements is to "remind each other it's OK to leave the mob"
Not sure I follow this one :P
- 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.
It's definitely not been all smiles and roses, and we have struggles like any team, but we also all agree that this has been an amazing experience and well worth any negative effects we've seen.
>> Constantly bringing people up to speed…
> Not sure I follow this one :P
The point came from (as did all of them really) past experiences of mine. I've found it can be incredibly painful and time-consuming to expect 100% of people to understand 100% of situations. A few years and companies ago we got to the point where there was an entire day of planning for a 2 week sprint, due to this requirement for total understanding. It was not an enjoyable experience, and I still don't believe it was a worthwhile tradeoff.
I believe everyone should understand the whole project at a high level. However, I'm very comfortable with only understanding a portion of the software or features being currently developed at the deep level required to work on them at that instant. I'm happy to let go and trust that the people who do understand will do a good job without my input. I can always learn about it later if I have to, because while I don't have to know about everything, I also don't just know about anything (ie never completely silo).
But: I'm willing to accept that this is my impatience at play, and that everything would be better off if everyone understood everything. It's just been historically (for me) been a very large price to pay.
I think the main point about "Constantly bringing people up to speed" is that this now happens without overhead, just sort of naturally, to the point that we don't even notice it.
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...
We do not have a particular person driving the discussion though, I do not see that that would help us in any particular way.
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.
> The person typing should not be driving.
What's the reasoning behind this? My guess is that it's to prevent pair programming from turning into lone programming with an observer. If that's the case it wasn't a problem for our specific situation. No matter who had the keyboard, there was collaboration. Why separate the keyboard from the person who can fastest/best get the code on screen for consideration?
> 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
Why? Of course you shouldn't snatch the keyboard out of someone's hands, but such behavior should be addressed in other ways than by making rules. I suspect it's not that, but something else. Even so, I have to wonder if it's a social issue that would still be better addressed in other ways than by imposing rigid structure.
Anyway, switching when we wanted did not seem to pose any problems. If we missed out on some benefits then I'd like to know about them.
- 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 the person go)
- I think personal space/time depends on the team, as it should. I have the opposite problem: I get bored and drift off online. I find other people in the room help me get back on track
- Nope. Actually that's the beauty of mob programming. Everybody is up to speed all of the time. It eliminates bringing people up to speed.
I think there are edge cases, one of which is bad teams, ie, bad mixes of people. But mob programming doesn't cause that. It might point it out a lot quicker, though. There are other edge cases, but the industry is still working through those.
The problem that mob programming solves is one that a heckuva lot of programmers don't even know exists: over-specialization in technology development.
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 :-/
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.
I think it's a cool idea. I'd still worry about people taking over, coasting, checking out or otherwise not getting to express themselves, but realistically that's a constant concern anyway, regardless of whichever development structure you take.
But I'd try it. I'd be exhausted, frustrated and very much in need of a drink after the first day, but that says more about me than it does the approach :-)
Beats me. But I really want to try :)
People say mob programming is great for keeping programmers on task, but just as frequently the reverse is true.
I've done a lot of accidental mob programing recently, and frequently, someone wants to take a break and show you this awesome video, they get enough support that lead typist goes to check it out, and suddenly you don't have just one off task programmer, mindlessly browsing YouTube, you have 5!
Until someone works up the courage to party-poop and demands that the team get back on task.
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.
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 with high quality.
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.
There are times when the machine is the bottleneck. Multiple monitors, SSDs, many cores, multiple machines... and I still end up waiting for (re)builds because I touched a header on each machine, trying to tackle a problem.
Having a whole mob blocked on those recompiles is going to be hideously wasteful.
On the other hand, there are times when I've "mob programmed" without knowing the term. The typical pattern was someone would loudly "WTF?", that'd pique the interest of a nearby programmer, and then a 3rd would be roped in via questions, as we knew they'd taken over the relevant mess of code... often oscillating between all eyes on the same bit of code, and spinning off to launch our own investigations into related bits...
I could imagine maybe this one could go either way, depending on the loudest personality type. Every team has a range of skill levels and styles, so there are inevitably people who skew towards more time writing code and less time thinking (as well as the opposite. Some middle ground is probably optimal).
A lot of these people might just never have really thought about and might not know any other way, and if the majority and/or loudest voice of the mob is more conservative about thinking through things before starting to code, it'll rub off on everyone else.
That said I do agree with your sentiment to some extent, I find I personally do better thinking on my own than in a group. Part of it is needing to go off in a ton of different directions and then consolidate the ideas afterwards, and in a group setting there's a pressure to talk through things aloud which dramatically slows this ability to branch out.
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.
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.
I switched to working remote full-time just because of people who wanted to talk with me all the time in the office.
Wow! That sounds more like social anxiety disorder than introversion.
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
Put me with a junior developer to just "pair program" and I'll be doing all the work. I've done this before as a training exercise; I think in about 12-16 sessions, each from 2 to 4 hours, the person I was paired with made one suggestion. And I still wasn't 100% efficient because I stopped a lot to explain what I was doing.
Put me in a mob programming environment with junior developers and it will be spectator programming, or I'll be wasting time "navigating" for a junior developer and cutting my productivity by 80%. I can't help but think that even teaching could be done better than that. (For reference, the person I paired with above insisted that it was extremely helpful and educational, even though it seemed hard for me to believe.)
Remember, to be efficient, pair programming has to produce more correct code than two developers would have done programming individually. Mob programming would need to produce 5x the correct output of 5 developers. It just seems insanely unlikely that me and another developer pairing could be more than 2x as efficient as me on my own. I just don't miss that many things or get stuck almost ever.
People come to me for design advice, so I don't think having someone there to work with me on the design side would be useful either; I don't spend a lot of time flailing, I just write out really solid code, really quickly. Aside from that: I am fully in support of design meetings to sketch out architecture.
Today in ~6 hours of programming so far I would have saved about 4 minutes tracking down something that I typed wrong and that broke the tests that a second developer might (probably would) have caught. But another senior developer could have written code for 6 hours as well if they hadn't been watching over my shoulder. If we're talking about senior developers, how can you not assume they'd be able to create more code with a keyboard and no interruptions?
It really just doesn't make sense that experienced developers could possibly be more efficient if only one person is typing. Junior developers? Sure, at least that's a reasonable assumption. They have so little idea what they're doing, putting two inexperienced brains together on the problem might mean they produce more than twice as much, because they collectively know enough to work far more efficiently together.
But for experienced senior level developers? I think the burden of proof is on the advocates of pair programming. Extraordinary claims and all.
The main exception is when you have two distinct subject matter experts working together on a problem. Even then I like to have two keyboards, so it's not strictly pair programming, but collaborative/synchronized programming, with expected frequent questions and back-and-forth. I did that once recently when connecting a C/C++ low latency video and audio streaming library to Unity3d and C#; I worked with a Unity expert and while he wired up the Unity side I wired up the C++ side. I laid out what the Unity part needed to look like, and he told me how Unity interfaces to DLLs on Windows. We frequently bounced ideas back and forth but were working on different parts of the code. Worked great; had the integration working in a couple hours, plus or minus.
It does seem to make sense that pairing senior engineers together would not benefit a team as much as pairing a senior with juniors.
I measure efficiency by less code not more
Really? So if I produce no code at all or just delete code, I'm being the most efficient, even if the goal is to add new features?
If you're going to pick on semantics, you shouldn't do it with a statement that's blatantly false on the face of it.
By "correct code" I mean code that is:
* Properly designed, refactored if necessary
You can't add features to "correct code" while strictly removing line count. No one is just counting lines of code here; your point is specious.
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.
I can imagine certain limited scenarios where this kind of problem solving approach might be useful, but on a day-to-day basis? Nope. No way.
The fact that someone made a website mobprogramming.org is perhaps the biggest factor that indicts this idea as a silly fad.
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.
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.
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.
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?
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. 
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.
 Maybe I was just lucky and had a great group when we were duing mob programming. But I doubt that.
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!
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.
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!
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.
I do love the idea of being able to not let the numerous tedious meetings interrupt progress.
 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]
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.
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.)
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.
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.
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.
- 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)
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.
uBlock Origin has prevented the following page from loading:
Because of the following filter
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.
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.
Our team name is "The Borg"
Welcome to Earth.
Most teams are not able to attract or retain talent, so they have to focus on maximizing and concerting effort instead.