This week's book giveaway is in the General Computing forum.
We're giving away four copies of Emmy in the Key of Code and have Aimee Lucido on-line!
See this thread for details.
Win a copy of Emmy in the Key of Code this week in the General Computing forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Paweł Baczyński
  • Piet Souris
  • Vijitha Kumara

mob programming

 
author & internet detective
Posts: 39586
781
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Has anyone tried or done mob programming?

I went to a workshop at a conference where they did a little demo. It felt slow and awkward. Pairing I get the benefit of. But not mobbing.

I sort of see how it would be useful for teaching. But even there, I think having more hands on typing time is useful.
 
Ranch Hand
Posts: 91
Netbeans IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Haven't done Mob Programming yet. In my case I don't know how would it go.
To me even pair programming is sometimes stretching things a bit...

 
Marshal
Posts: 14322
237
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Did they do a lot of explaining on what was happening in the demonstration?  If pair programming is difficult to do effectively, mob programming is X times more difficult, in my opinion, X being a factor that's proportionate to the number of people involved in the mob.

Here are some rules of thumb:

1. Everyone should be engaged, either actively listening or actively discussing choices and options, or actively researching
2. Rotate the driver role frequently; the keyboard should change hands at least every 5 to 10 minutes
3. Have a mini retrospective after each session. Talk about the interaction, the rotation, the mechanics, anything you think you can do better. Also talk about things that worked and how you can make it work even better. Always have the goal of learning something from the session and finding a way to get a little better next time.
4. When you're still adopting and learning, focus on doing one thing better. Like maybe switching the driver role frequently.
5. Break up the session into small chunks of time. Use the Pomodoro technique

These are just a few things we did when we developed the practice out of necessity on my team. We were all remote and we had to do what we called "group programming" over WebEx. We all really enjoyed it and after a while, the feeling of slowness was replaced by the satisfaction that we all understood what the code did, that our bus number was higher, and that we had all contributed to creating some really high-quality software. As a tech lead, it gave me a chance to share what I knew about design and for my team to learn every day.

Caveat: We had a delivery schedule but it was one that we had included time to learn and adopt new practices.  If you are in a situation where you have other people breathing down your neck, waiting for you to deliver something and you are unable to push back and say, "This is how much stuff you can expect to get from this team and this is when you'll get it," then I would advise that you don't try to learn how to do mob programming with the goal of delivering faster. That's not going to work.
 
Junilu Lacar
Marshal
Posts: 14322
237
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Mano Ag wrote:
To me even pair programming is sometimes stretching things a bit...


I know quite a few reasons why people feel that way. I'm curious, what are yours? What gets "stretched"?

The biggest reason I see that people fail to get as much out of pair programming as they could is that they don't fully understand the interactions that need to happen between the driver and navigator. They don't know how to have what I call a "fruitful conversation," which is really what pair programming is good for. Most people also get caught up in mechanics and implementation detail.  If the driver and navigator are not exchanging ideas, bouncing their interpretations of what needs to be done at their respective levels of abstraction off of each other, then they're not having that fruitful conversation that gets them both on the same page and in synch with the code.
 
Junilu Lacar
Marshal
Posts: 14322
237
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've been studying French using Dr. Paul Pimsleur's audio discs. Disc 1 in each set (I'm up to French II now) starts with an explanation of how the method works and it really resonated with my experience with pair and mob programming and how I teach it.

In the Pimsleur method, you are asked to first listen to a few phrases of the foreign language as spoken by a native speaker. Then you have to repeat the phrases out loud, trying your best to mimic how the native speaker said it. You can't just follow along silently. You have to actually say the words out loud.

They claim that the reason they want you to do this is that when you say the phrases out loud and you repeat them several times, new neural pathways are created in your brain that would not be created if you simply silently repeated the phrases inside your head. This made a lot of sense to me.

If you look over my past posts about TDD and pair programming, you'll see that I often encourage people to read their code out loud because there's something different that happens when you actually hear your code. I find that having someone else read my code out loud can help me find flaws in my logic and identify the parts that are unclear, misleading, or just plain wrong.

When you read the code silently, I think our brains have a tendency to fill in a lot of missing context that you have floating around in your head and we think the code is understandable and clear enough when it actually isn't. When we read code out loud, it becomes clearer what part and how much of that context is actually being left out in the text of the code.

In the Pimsleur method, you're not allowed to take down notes or look up words in the dictionary either.  This also resonated with me because I have been teaching people to not look at the code on the screen when someone reads it out loud. Again, it's to get around our brain's natural tendency to "fill in" the missing context. I'd even bet that the part of the brain that causes us to see optical illusions where the brain "fills in" the picture is the same area that's at work here.

This is why I always say that Pair and Mob programming is about the conversation developers have with each other. Effective pairs and mobs are constantly reading the code out loud and discussing its intent and how well it matches the implementation.
 
Jeanne Boyarsky
author & internet detective
Posts: 39586
781
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:Did they do a lot of explaining on what was happening in the demonstration?  


Not really. There was a preface which included "some other guy explains this better" and then the demo. Which was made up of 4 volunteers. Only one of whom had done mob programming before. I was one of them.

Thanks for sharing your experience.
 
Junilu Lacar
Marshal
Posts: 14322
237
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No problem. It's a bit disappointing to hear how the demo you were part of was done. Seems like that kind of experience could create more doubt about the technique than interest. If they were going to get people from the audience as volunteer participants, I would have expected someone to at least facilitate and guide the conversation by asking volunteers open-ended questions that make them think about design, give them a chance at the keyboard, ask them to suggest the next test, and things like that to keep engagement and participation high.
 
Jeanne Boyarsky
author & internet detective
Posts: 39586
781
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Everyone got a chance at the keyboard. I found my turn maddening. Being told "go to this method", "type x on this line", etc feels silly. I'm used to pairing where the person typing has more autonomy and the other is focused on higher order concepts. I did ask after and he said it isn't usually like that.

He "simplified" by having only one person be the navigator for the first few turns. So I had to sit there silently as the thing went down the wrong path. We were implementing FizzBuzz in JavaScript and they coded i == 15 instead of using mod.

There wasn't much guidance. I did "suggest" two tests. If by "suggest", you mean "dictate what test to copy and what parameters/return value to use." I was the only one who did that.

Funnily, he commented that it was good for others to be looking stuff up on their computer and referenced me. (I was checking email; hardly engaged.)

I know this isn't representative of the technique. But yeah, it didn't leave me with interest to find out more.
 
Bartender
Posts: 3601
151
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I must admit to not knowing what mob programming is, and actually not what Pair programming is.

The only thing that comes to mind is last years Day of Global Code Retreat, if I remember the name correctly. There were groups of two and three, thinking about Conways life. Problem was that we all had our own ideas, and it was hard to listen to the ideas of others (as Junilu rightly remarks: all busy with the implementation). You did listen, of course, but at the same time you were thinking 'yeah, yeah, but when I come home, I will follow my own ideas...', and, so I thought, the whole concept is nice, but effectieve? Hmmm...
 
Junilu Lacar
Marshal
Posts: 14322
237
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jeanne Boyarsky wrote:I found my turn maddening. Being told "go to this method", "type x on this line", etc feels silly. I'm used to pairing where the person typing has more autonomy and the other is focused on higher order concepts. I did ask after and he said it isn't usually like that.



On my last coaching engagement, I told participants that pairing/mobbing isn't dictation/transcription. It was the navigator giving the high-level idea, then the driver taking that idea and translating it into what he thought was the appropriate implementation. The discussion would revolve around how to verify, through unit tests, that the idea was correctly codified in the software and whether or not other people coming into the code could readily understand what the idea was by reading the tests and the implementation code.
 
Junilu Lacar
Marshal
Posts: 14322
237
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Piet Souris wrote:Problem was that we all had our own ideas, and it was hard to listen to the ideas of others (as Junilu rightly remarks: all busy with the implementation). You did listen, of course, but at the same time you were thinking 'yeah, yeah, but when I come home, I will follow my own ideas...',



This is why it's so difficult to learn these techniques if nobody has a good idea of how it's supposed to be done, what the flow of conversation should be like, etc. I find that most developers naturally are always thinking about implementation. Very few developers start with high-level abstract ideas that express purely intent only. There's almost always going to  be some kind of implementation detail in what they say.  

This is where I come in as a coach and help steer their thinking and conversations in the right direction, always pulling the navigator(s) up out of implementation-level thinking and telling them to find a more abstract way to describe their intent. Then we let the driver go ahead and think of the implementation.  If the driver gets stuck, the navigator gets the keyboard and becomes the driver. The former driver then becomes navigator and the process of pulling someone out of implementation-level thinking up to a more abstract intent-based level of thinking begins again.
 
Junilu Lacar
Marshal
Posts: 14322
237
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
FWIW, it took me about two years of intermittent solo practice in the evenings to learn how to separate the two levels of thinking. Lots of repetition, lots of talking out loud to myself (just loud enough to hear myself and soft enough so as not to make my family think I was losing it) - I applied things that I learned in the evenings of practice in my daily work and that helped me a lot as well.

This is why I tend to be skeptical of anybody who says that TDD and pair-programming is easy to learn or that it can be learned with very little guidance. There are many nuances to the techniques and it really is a skill much like playing sports, practicing martial arts, painting, playing an instrument, etc. You need lots of quality practice. See my sig.
 
Marshal
Posts: 66158
250
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:. . . lots of talking out loud to myself . . .

You do the same with theses. Sit in front of a mirror and read the chapter out loud. Best done when there is nobody else around.

so as not to make my family think I was losing it . . .

I have never had that problem; my family all know I lost it ages ago.
 
Saloon Keeper
Posts: 10750
229
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've always had good experiences with pair programming. At university we did assignments where we would work on the same system in pairs, and for some reason I enjoyed it. In my current job, I'll occasionally ask a colleague to join me behind my PC (and even take over my keyboard) if I'm stumped on a problem, or if I just need more brainpower to get a problem fixed quickly. We communicate in high level abstractions, and only occasionally will I make a remark about coding style.

I don't think it's good to do it all the time though. For simple problems you just want to get it done by yourself, without the overhead of sharing a system. We have code reviews during pull requests so colleagues can get acquainted with each other's code that way.

Mob programming I'm skeptical about. I think the law of diminishing returns applies here. It's great to bounce ideas off of somebody, but as a group behind a system it just becomes cumbersome.
 
Junilu Lacar
Marshal
Posts: 14322
237
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Woody Zuill started pushing mob programming at about the same time we were doing what we called group programming on my team, back in 2008. At Agile 2013, there was a team that was demonstrating it in an open space and they told me they would never go back to doing just pairing. I think four people in a mob is probably the best size if you're going to do it. That was our experience, although there were only four people on our team, which was also by design.

We didn't do it all the time but did it more often than not. Anything where we needed to write tests, do any kind of design activity, or write some production code, we preferred to do it at least in pairs. We did it for the instant code review and having a shared understanding of the code and tests.
 
Mano Ag
Ranch Hand
Posts: 91
Netbeans IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Mano Ag wrote:To me even pair programming is sometimes stretching things a bit...



Junilu Lacar wrote:I know quite a few reasons why people feel that way. I'm curious, what are yours? What gets "stretched"?



In my view what gets stretched is the soft issues related to software development. After so many years in this business I am convinced
that "it is not all technology". Soft issues such as how well the team communicates, just to name one, can make or break a project.

Going back to the "Pair programming" and "Mob Programming", although I am not a native english speaker, I think the names
themselves have a strong connotation of "implementation" or even "coding" alone. From my experience, people tend to see development
as just "implementation" or just "coding". If I had my way I would call these "Pair Development" or "Mob Development". The reason is
that such terms can then encompass the idea of what Junilu has called "fruitful conversation" and what Jeanne has called "higher order
concepts". Personally I call that "conceptual reference points". Ingredient X if you will.

In my opinion if "Ingredient X" is lacking it doesn't matter how many typyists you have, as noone knows what is the correct thing to type.
 
Junilu Lacar
Marshal
Posts: 14322
237
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Mano Ag wrote:I think the names themselves have a strong connotation of "implementation" or even "coding" alone. From my experience, people tend to see development as just "implementation" or just "coding". If I had my way I would call these "Pair Development" or "Mob Development". The reason is that such terms can then encompass the idea of what Junilu has called "fruitful conversation" and what Jeanne has called "higher order concepts".



Your reasoning doesn't quite add up to me and actually seems self-contradictory, particularly the part that I italicized and underlined.

In my opinion if "Ingredient X" is lacking it doesn't matter how many typyists you have, as noone knows what is the correct thing to type.


That's my point exactly, pairing/mobbing isn't about taking turns writing code. That's just a mechanism. It's about getting everyone on the same page through focused discussion and codifying that shared understanding in software in such a way that is clear and well-organized so that anyone not involved in the discussions that went into writing the code can still understand the ideas and thought processes of the authors at the time the code was written.
 
Mano Ag
Ranch Hand
Posts: 91
Netbeans IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


Junilu Lacar wrote:Your reasoning doesn't quite add up to me and actually seems self-contradictory



Acknowledged. My idea is that Development includes Programming but Programming does not necessarily includes Development. "Pair Programming" as a term to me is a misnomer. Just that.
 
Junilu Lacar
Marshal
Posts: 14322
237
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@Mano: I get where you're coming from but I have no problem with the term. For me, code is design and writing code, i.e. programming, includes all the things I've talked about here.

"Development" to me has a wider scope than what it seems to have for you: It includes activities besides programming, like planning, talking to the end users, doing integration testing, security testing, setting up and managing the deployment pipeline, and every other activity we need to do to deliver software to production. For me, software development includes everything from conceptualization to delivery.
 
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mob Programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer. This extends the concept of pair programming from two people working together to the entire team continuously
 
Jeanne Boyarsky
author & internet detective
Posts: 39586
781
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Junilu,
We did a "four people; one computer" thing at work this week. However, it was two people from our company and two people from a vendor. So the people from our company knew Java and the people from the vendor knew the product we were integrating with.

That worked well. But it was because of the split expertise. And it was still tiring/not sustainable over a longer period of time. Also, there was lots of one or two people not paying attention/researching other things/doing/email etc. So it felt inefficient while still being productive.
 
Junilu Lacar
Marshal
Posts: 14322
237
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeanne,

That's pretty typical from my experience. Did you do a quick retro after the session?  Next time, try to and bring up the concern that people are not engaged or are doing things not related to the work being mobbed on. Then put something in your team working agreements. It could be that you all agree to leave phones in a basket. Or no other computers besides that mobbing computer.  Or to set aside the mobbing time as "busy" on their calendar.  There's all kinds of things like that you can get people to agree to. Just don't keep quiet and stew on it if you feel it could be better. It's always about getting better so bring it up if you know a way that might help.
 
Jeanne Boyarsky
author & internet detective
Posts: 39586
781
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Junilu,
I'd have to be convinced it is valueable to help sell it. I don't think I'm at that point at this time. I was one of the people doing other things part of the time when I wasn't driving.
 
Junilu Lacar
Marshal
Posts: 14322
237
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mobbing isn't for everyone. I know of teams that won't do their work any other way but that's quite rare as far as I can tell. The teams I have worked with mobbed on difficult problems or work that the entire team needed to understand. Other things, people could work on them solo or in pairs. A lot of it has to do with the people and personalities you have on the teams as well. I can think of a few people I didn't enjoy pairing with and I can think of a few people I'd enjoy mobbing with most of the time.

In those moments when you weren't engaged, can you remember why you wandered off into doing something unrelated? Were you bored or did you just need to do this other thing that couldn't wait until later? Or was it for some other reason?
 
Jeanne Boyarsky
author & internet detective
Posts: 39586
781
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:Mobbing isn't for everyone.


I don't know if it is for me. I think that opinion comes with trying it and experience.

Junilu Lacar wrote:In those moments when you weren't engaged, can you remember why you wandered off into doing something unrelated? Were you bored or did you just need to do this other thing that couldn't wait until later? Or was it for some other reason?


A mix of causes
  • We were in a room for three days straight which is a long time to pay attention
  • My teammate would go to checkout a password or something that I know takes a minute
  • I'd go to check email "real quick" and then get lost in something else
  • I went to lookup something relevant and got distracted
  • I knew I was off the day after this three day engagement and that other teammates needed information from me

  •  
    Junilu Lacar
    Marshal
    Posts: 14322
    237
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Jeanne Boyarsky wrote:A mix of causes

  • We were in a room for three days straight which is a long time to pay attention
  • My teammate would go to checkout a password or something that I know takes a minute
  • I'd go to check email "real quick" and then get lost in something else
  • I went to lookup something relevant and got distracted
  • I knew I was off the day after this three day engagement and that other teammates needed information from me


  • I bet most if not all teams that try mob programming will see these kinds of things happen. A retro at the end of the day to reflect on how things went and things that are a concern can probably help the team agree on norms for mobbing.

    Another thing, too: you don't have to spend days on end mobbing if you don't think it's helping you get better at delivering and most certainly not if you think that the slowdown you're experiencing is not worth any gains, whether those be short- or long-term. I think a team should be able to determine what works best for them. If your primary goal is to deliver, then do what enables you to do that most effectively. If your goal is to learn how to mob, then give yourselves time and room to falter or fail; that's where most of the learning comes from, as long as you reflect regularly and adapt appropriately.  If it's a mix of delivery and learning that you're shooting for, then your team needs to find where the tipping point is between delivering and learning and balance them out.
     
    Jeanne Boyarsky
    author & internet detective
    Posts: 39586
    781
    Eclipse IDE VI Editor Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    My primary goal was to get as much done as possible while the vendor was there to help. We did that.
     
    I yam what I yam and that's all that I yam - the great philosopher Popeye. Tiny ad:
    Java file APIs (DOC, XLS, PDF, and many more)
    https://products.aspose.com/total/java
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!