Mob Programming is a technique to get all the team to work on a project at the same time. I Mean all developers, QA, PM and others, everyone working in the same screen with a single keyboard.

I have first heard at this term in the Podcast ChangeLog and I wanted to try it from the day one. I have made similar setups in the past but I would like to do a project back to back with it to see the results.

The idea is that the team will work on a problem at once and fix it and move to the next problem once it is fixed. All coding one single computer. Of course in the age of remote work it means all the team is working on one screen share and the rest of the team is working from their houses and watching someone write the code and sharing ideas. Not totally ideal but still very effective.

Why does it work?

It works because it focuses on a single problem at once, and optimizes communication since all the team is in a room and talking about the same problem. If there are disagreements, they can be solved in a few minutes and there is no need to call meetings; blockers are removed as soon as they show up and code errors are corrected as soon as the person typing them puts them in.

I have applied it to real challenging projects and the results are astounding, how quickly you can fix a problem that would take weeks, or that any normal developer would procrastinate too much to try to get it fixed.

What is Good about it?

Once the code is pushed PR is approved into seconds

As all the team worked together in the solution, once the PR is open the speed to prove it is much faster, everyone already have context about it and 99% of the questions will never be asked and therefore it will be merged much faster.

Early QA validation

The QA ask questions earlier in the process and even suggest code changes to avoid problems that the devs did not anticipate. Test cases can be written before the code is finished.

Design flaws are seen before the changes go too far.

With the architect on the code, if the design deviates too much from the expected, it can be corrected before it becomes too big to change. Remember that proposed change you made, which you thought would change 20 lines of code? When the PR was opened, you saw 2k lines added? That would never happen because in the first 100 lines you could make that call and change the direction.

Much less procrastination

It is easy to procrastinate when you are working alone on a task, when the team is working on a task as a hole it is much harder to lose focus and start wondering. In my own experimentation I myself will check much less my phone and will even skip non critical phone calls and meetings because the coding sessions get too exiting to stop.

Leaning spreads much quicker

As all the team suggests changes and collaborates to produce one code, the speed with which the knowledge spreads will be much faster than usual. Once one team member claims they know something, they can teach it once live on the code and all the team learn it on time.

It is Pair Programming on steroids

If you have ever tried pair programming and you liked it, imagine it multiplied by N (being N the number of people on your team). And you have the test team and the product team there to share their understanding of the task being coded at the time of coding. When problems show up, if anyone can solve it, they can take it and solve it right away, or everyone can start researching the solution. Once one solution is found, everyone starts to debate if that solution is acceptable.

What is bad about it?

Very demanding in attention for those driving it

For those running the session (normally me) it is quite exhausting, I use to run 4 hours of mob programming sessions and in the end I would already be supper low on energy and could not get too much more done in the day after that.

My take to make is less exhaustive is to make it in smaller sessions like 2 hours in the end of the working day.

Team may not few comfortable sharing their screen

This happens more often than I would expect; team members will not like to share their screens to collaborate and will be selective in what they share and show, and the experience will be poor.

I usually start addressing this by sharing my screen and setting the tone for collaboration. I don’t expect people to be too protective with their work laptops, and they should be able to share their full screens at any time. I do it, and I encourage people in my team to do the same during this sessions.

Don’t do it in tasks where feedback cycles take much time

For example, if you need to debug a problem on CI and it will take 5 minutes to run each test, it is probably not a good idea, because everyone on the call will get bored watching the build and too many parallel conversations may happen and the focus will be lost. I would rather focus on productive tasks where the goal is clear and the feedback cycles are shorter, like coding an API or screen or even debugging a problem.

Conclusion

Mob programming is a great technique; in all the opportunities I have applied it, it has been very helpful. It can be expensive and you will need to have a strong and mature team to make it work. It works quite well in a remote environment, provided the team is willing to work with it. If you have not yet tried it, get your full team on a call, pick the hardest problem you have to solve, and start coding it and taking decisions just-in-time, and share your experience later; the results will speak for themselves. My only concern is how demanding it can be; if you try to do it for too many hours a day, too many days in a row, be careful not to burn yourself out in the process.