Practising Mob Programming


In the past edition of Socrates UK, I met Gianfranco Alongi who told us about his team's experience with  Mob Programming. It was the first time I heard about it. As the site says, Mob programming is people working at the same time, in the same space, at the same computer, on the same thing. Gianfranco said it was very useful for them.

At the beginning of November three of my fellow craftsmen and I joined a team of other 12 developers to work on a new project. We are building a DMS (Dealer management system) and an IMS (Importer management system). The project is very exciting but we don't have a clue on the domain. We are also a lot of people with different programming styles. So we decided to give Mob Programming a try and after a few weeks the results are very positive.


Some lessons we have learned along the way:

  • Like with pair programming, navigators should take notes whilst the driver is at the keyboard, rather than disturbing him constantly.
  • Only when the driver raises his hands off the keyboard we are allowed to discuss.
  • Rotate frequently: it's faster to jump in the keyboard and do it yourself than trying to explain the code you envision.
  • Limit the group size to 5 or 6 people. We find that 4 is a good number, more than that is not being productive for us. Sometimes it's useful though, when we want to define conventions for the whole team.
  • The group should be stable: if new people join the discussion in the middle then we have to explain again and again the code and the decisions we have already made. It's like the never ending story.
  • At some point I had to leave a session right in the middle of something. When I came back a colleague told me that the people who were shy or less proactive during my driving period, started proposing interesting ideas during my absence. The people considered "seasoned" or "experienced" should go away from time to time for the others to feel empowered.

So far the project is just fantastic. People are awesome, learning incredibly fast, very enthusiastic. Everyone wants to learn and contribute. We are all learning a lot and doing our best. I can't think of a better project. We are very lucky.




Enjoyed reading this post?
Subscribe to the RSS feed and have all new posts delivered straight to you.
  • R. Chavarría T.


    I’ve heard about Mob Programming before, but I have some doubts. For instance, lots of people complain about the Pair Programming productivity (better or worse than Single Programming, it’s not my question here). Can you imagine their complaints about having twice or three times more people working on the same problem at the same time? Have you talked to people don’t like Pair Programming about Mob Programming?

    And a last question: what are the best situations to practice Mob Programming?

  • Carlos Ble

    The project’s bottleneck is never the keyboard. I don’t think I now many people who really know how to practise Pair Programming and don’t like it. Most people I know don’t like it because don’t know how to do it properly.
    In our situation, making sure we are all on the same page is crucial. Imagine 16 developers writing code from scratch, each with different styles, different ideas. Some of them with little knowledge of BDD, TDD and DDD. Some with little knowledge about persistence or responsive design…. We would create a lot of lines of crazy code quickly and then suffer those lines for months or years.

    Code is way more expensive to maintain than it is to write. This is what many people forget. Code is read many many more times than written.

  • R. Chavarría T.

    Yep, Pair Programming is similar to TDD in what you say: many people don’t like it but they don’t try a bit harder to really understand if that practice works well or not for them.
    It seems that you see Mob Programming useful for: starting a new project, to align coding styles, maybe an architecture,…; starting a big change or a big evolution in a running project…
    Thanks for your answer!

  • Carlos Ble

    Exactly mate, you get the point 🙂 By the way, I’ll watch your screencasts sometime in the near future. Thanks

  • R. Chavarría T.

    😀 Don’t worry about the screencast, it’s not extremely important, but I’d appreciate some feedback. At least, now I know you didn’t forget them. Thanks a lot