Dieser Artikel ist auch auf Deutsch verfügbar
Cast yourself back to the year before the pandemic. A team of three at the home office is getting started on a new project, entirely from scratch. Every day they meet online in their Zoom room and begin developing software. They are using the method known as remote mob programming (also called remote ensemble programming or remote team programming). The typist shares their screen and types what the other two tell them to. The typist acts like a smart input device for the other two, who are then better able to focus on the analysis of problems, the consideration of alternative solutions and the detailed design of established solutions. It all goes surprisingly well for the three developers. So well, in fact, that at least one of them no longer wants to work in any other way.
The only problem is that handing off the baton to the next typist proves challenging online in the Zoom room. At the office, they could do this in seconds by simply passing over the wireless mouse and keyboard. After a few initial attempts, a workable solution is discovered: Manually switch to a temporary git branch, create temporary commits there, and then, when the work is finished, bring the changes back to the original branch. However, executing all these steps manually is something of a chore. A tool was needed. And that is how the mob tool was born.
The mob tool is written in Go as open source software under the MIT license and is available on GitHub. The first version was released in April 2020. As of February 2022, the tool is now in version 2.4.0 with over 20,000 downloads and more than 850 stars on GitHub. The tool even made it into “Technology Radar Volume 25” and is rated there as worth pursuing.
Basic functions of mob
The tool offers three basic functions: mob start, mob next, and mob done. It is a little bit like a board game. Each typist begins their turn with mob start and ends it with mob next. The feature is finished when a turn is ended with mob done. Check out Figure 1 to see what these basic functions are really doing.
Carola, Maria, Mona and Raphael are using the remote mob programming method to develop a new feature in an online shop. Carola begins as the typist, sharing her screen with the others, opening the project folder in her terminal and starting on the main branch. She enters the command mob start. The mob tool then creates a new temporary work in progress (WIP) branch, which is used only for developing the feature. The name of the WIP branch is derived from the original branch according to the pattern mob/<Ursprungs-Branch>. In our example, the original branch is the main branch. The derived WIP branch is therefore mob/main.
The rest of the team tells Carola what to do. After a certain amount of time has passed or when a test has been fully coded, for example, it is time to switch places. To do this, she simply enters the command mob next in her terminal to hand the source code over to Maria. The mob tool creates a WIP commit and pushes it directly to the remote repository. It could be that the current code base doesn’t even compile or that the test fails. That’s totally fine! This is exactly why the WIP commit is used, which typically features the commit message mob next [ci-skip]. This marks the commit as a work in progress and prevents a CI pipeline from failing due to compiler errors. The WIP commit is also created and pushed in a way that bypasses any Git hooks since these aren’t meant for temporary code states.
Maria takes over the role of typist. She now shares her screen instead of Carola. She also goes to the project folder on the main branch in her terminal. Then she types the command mob start as well. The mob tool automatically checks out the WIP branch with the changes made by Carola, and Maria can now continue working on that basis. To hand the source code over to Mona, Maria also enters mob next on the command line. This causes another WIP commit, which is pushed onto the WIP branch.
Now Mona takes on typing duty. When the feature is fully implemented, Mona enters the command mob done. All WIP commits of the WIP branch are combined with squash and packaged as changes in the staging area of the main branch. The mob tool automatically deleted the WIP branch from the remote repository and from Mona’s local machine.
Mona only has to create a commit with an informative and carefully chosen message and then push it. A few minutes later, the new feature is live and ready to be used.
The perfect handover
Of course, using the mob tool does not guarantee a handover in mere seconds without interrupting the others in their discussions. To achieve this, there is one more thing to consider. Let’s take a closer look at the handover from Carola to Maria. We are coming in just at the point when Maria is still sharing her screen but wants to perform the handover. To do this, Maria enters mob next in her terminal, as described above. Then Maria does nothing. She does not end her screen sharing, and she does not move the mouse cursor or type anything. She has initiated the handover with mob next and must now wait for Carola to continue. Of course, Carola is still attentively watching the shared screen. When mob next has been executed successfully – which can take a few seconds – Carola immediately starts sharing her screen with a keyboard shortcut. This automatically ends Maria’s screen sharing, and Maria can finally check her email unobserved. Meanwhile, Carola switches to her terminal and enters mob start. Once mob start has completed successfully, the handover is finished. Because neither Maria nor Carola had to speak to accomplish the handover, Mona and Raphael were able to continue discussing how to solve the current problem undisturbed.
Unfortunately, this handover doesn’t work with every video conferencing tool. There can be considerable variance with regard to handing over the screen sharing without an interruption, global keyboard shortcuts for screen sharing and a stable screen layout when “stealing” the screen sharing. In our experience, a perfect handover is only currently possible with Zoom. But we are optimistic that it will also be possible with other video conferencing tools in the future.
Timing is everything
In collaborative work such as remote mob programming, it is tremendously important to regularly swap the role of typist. If this is forgotten, the typist will eventually tire out and other members of the team may become distracted and start reading Java Magazin on the side. To help teams swap roles regularly, the mob tool features its own local timer. For example, entering mob start 10 will start a ten-minute timer. When the time is up, the current typist will hear “mob next” in their headphones.
It is also possible to combine the mob tool with the Mob Timer. This is available as a web application at timer.mob.sh. The advantage: In this case, the timer is not merely local; it is centrally shared so that every team member can see it.
To use the Mob Timer, a room is required at timer.mob.sh. As shown in Figure 2, it is only necessary to enter a name to join the room. In our example, we created a room called “javamagazin”.
Figure 3 shows the active room “javamagazin”. To start the timer for this room using the mob tool, each member of the team must set the environment variable MOB_TIMER_ROOM to the name of the room. Then the timer can be started as usual either with the command mob timer <anzahl Minuten> or mob start <anzahl Minuten>. The Mob Timer will then automatically be visible to everyone who has the website open to the correct room, and a tone will be played when the time has elapsed. In addition to the tone, the Mob Timer can also send notifications to the browser, and it maintains a 24-hour history of the mob session (Fig. 4). Users of macOS can even get another small helper for their taskbar in the form of an app from the App Store, which then counts down the time similar to the website.
In addition to timing the mob session, the timer can also be used for breaks. The mob tool offers the break command for this purpose. If you wish to take a ten-minute break, simply enter the command mob break 10. As shown in Figure 4, this starts a ten-minute break timer, which is indicated by the coffee cup symbol.
