A lot of people are doing remote Mob Programming sessions now that most of us are working from home. I participated in a few and hosted one in the past week. It’s been a good learning experience. I feel as if we (as an industry or community) are rapidly learning how to make this approach work for regular work, virus or no virus.
Companies often have financial resources available to enable them to purchase licenses for remote collaboration tools that charge on a per-user basis, like Use Together. For individuals who are hosting mob programming sessions for free from their own homes, this is not viable. People are using various low-budget or no-budget workarounds that result in less-than-seamless collaboration. Therefore, managing the process of switching drivers in the mobbing session can be painful.
Local environment setup
For mobbing sessions involving client team members who are working from home, the procedure I’ve been using involves combining Zoom with the client’s version control system. Team members already have local development environments configured to work with their code bases, and VPN clients to give them access to their corporate networks.
For public mobbing sessions, my experience so far has been that sessions using Cyber-Dojo have gone more smoothly than sessions requiring participants to set up development tools on their local systems. Woody Zuill’s mobbing sessions use Cyber Dojo, and the experience of switching drivers and navigators was better than in sessions requiring local environment setup.
For my session on Prime Factors in Kotlin, I tried Cyber Dojo and discovered the “Test” function for Kotlin times out. I think they’re still working on Kotlin support. So, participants had to set up a Kotlin development environment individually. This caused delay in getting started.
The following day I joined one of Jeff Langr’s pubmob sessions. The project they were using also required local environment setup, and the group had changed to a different project than the one documented in the readme. Several new participants had to set up their development environment after joining the session. This caused delay for them to get started.
In my case, I was unable to resolve the incompatibility between Java 14 and Groovy (a documented bug), and also unable to install Java 11 due to a different issue (probably local). But when you have just a few seconds to set things up in a way you didn’t expect, you have to hope everything works correctly on the first try or you just don’t have time to deal with it in the moment.
Things to try differently:
- When preparing a session, minimize the amount of local setup required to work. Cyber Dojo is a good platform for most of the basic code katas. If you want to work on refactoring or legacy remediation, that is probably not an option. On the other hand, if the amount of starter code is not too great, you can create a Cyber Dojo session and paste the starter code into it to prepare for the session.
- When preparing a session, be sure to update the documentation about the session in time for people to configure their local environments. When I joined Jeff’s session, I found out the group had decided to change projects since their last meeting. I had set up the original JavaScript project locally to prepare for the event, but the group was working with a Java project instead.
- When you must ask participants to configure a local environment, be explicit about any version dependencies and other “gotchas” they need to be aware of. The issue with Groovy on Java 14 prevented me from getting the most value from Jeff’s session. A participant in my session had an issue with IntelliJ IDEA configuration which was ultimately fixed by running “invalidate caches and restart”. We still don’t know what the issue actually was. That’s the universal “fix” for IntelliJ IDEA, conceptually equivalent to slapping the side of your TV set to fix the picture.
- When you are planning to join a session, pay attention to the setup instructions the facilitators have prepared. Configure your environment and try to verify you can work with the project, if possible. For instance, if they have prepared starter code, see if you can run it or run the provided test cases well before the session starts, so you will have time to deal with any issues with dependencies or configuration settings.
- When you are planning to join a session that requires local environment configuration, consider preparing a pristine environment from scratch and packaging it in a container, running it in a local VM or using a cloud service to host it. That way, you avoid any configuration conflicts with your “real” local setup. Another advantage is you can avoid accumulating all sorts of libraries and tools on your local system as you prepare for various mobbing events that use different tool sets and stacks. Some of those “extra” things could potentially interfere with work you do in your day job.
- Some people experienced issues pushing code changes to Github for one reason or another. When preparing a session, be explicit about what participants will have to do to gain commit privileges on the repo you will use in the session. When preparing to participate in a session, take care to check that you have the necessary privileges before the session starts. If you don’t have a Github ID, set one up. Tell the facilitator what your ID is. When they invite you, respond to the invitation. Set up your local git client to use appropriate authentication mechanisms so your push commands won’t fail for that reason.
- When preparing a session that depends on Github, consider a setup step for participants that asks them to update a text file by adding their name to it, commit, and push the change. That ensures they can push to the repo and also provides a list of participants, which can be helpful for managing driver rotation. (Thanks to George Dinwiddie for this suggestion.)
Switching drivers
In my session, the process of switching drivers wasn’t smooth. The current driver would push to github and stop screen sharing; the new driver would start screen sharing and pull from github. In principle that sounds pretty straightforward, but in practice it turned out to be cumbersome. With a three-minute timer, we spent as much time doing the switch as we did doing the kata.
The process of switching drivers in Woody’s sessions was better than in mine, mainly (I think) because they were using Cyber Dojo instead of individual local setups. They still used the procedure of stopping the screen share and having the new driver start sharing, but they only had to press “Test” instead of doing git push and pull.
The process of switching in Jeff’s session was the best of the three. They used the open-source tool mob to support changing drivers. The experience was much smoother than in the other sessions, where we didn’t use any special tools to support the mobbing process as such.
Things to try differently:
- Accept fewer people into the group. My session had 10, and in a 90-minute time-box we were not able to have everyone rotate through twice. Some people only had one opportunity to act as navigator and driver.
- Increase the time limit for driver rotations. While a three-minute timer works well for collocated teams, when you have to manually stop/start screen sharing and do push/pull commands, the overhead of switching drivers can chew up a lot of time. A five-minute timer may be preferable. (Thanks to Eswaran Balakrishnan for this suggestion.) That also means fewer rotations are possible, so you’d want to limit participation, as well. If you can solve this problem in the “other direction,” by obtaining suitable remote collaboration tools so you can support more rotations of shorter duration, it would be preferable.
- If you can use development tools that support remote collaboration, they can save some trouble when switching drivers. Microsoft VisualStudio and VSCode have a feature called “live share” that works well. IntelliJ IDEA lacks such a feature, but there are open source projects you can look for that are trying to support it. I can’t vouch for them personally. There used to be a plugin for Eclipse that supported remote collaboration, but it is no more. Screenhero has bit the dust, and screen.so isn’t what Screenhero was.
- The “mob” tool mentioned above seems to work quite well, and alleviates most of the hassles of switching drivers. If you will be using Github as your version control system, this is a good solution.
- Consider keeping the driver in place long term while switching navigators. That way, there is only one development environment and one copy of the code base in play. The driver can keep screen sharing going the whole time. You might want to switch drivers occasionally so that everyone has a chance to work as the navigator; or you might have a facilitator or helper available who is willing to be the permanent driver. Bear in mind this approach might interfere with some of the value added by mob programming. I suggest it only as a workaround for excessive driver-switching overhead. (Thanks to Eswaran Balakrishnan for this suggestion.)
Summary
Those are the main things I’ve learned this week from various remote Mob Programming experience. I think it’s a very promising way of working, and I hope people will continue to offer remote mobbing sessions and participate in them, so we can learn how to run them effectively.