This content originally appeared on DEV Community and was authored by Attila Komaromi
All Day Mobbing Can Lead to a Poor Developer Experience
What is mobbing?
Mob programming is like pairing, but with 3 or more people, sometimes up to 8 or more. It doesn’t have to be just programmers in the mob, it could be designers or product managers too, for example. There will be one keyboard, mouse, and monitor—only one person in control at a time, who is dubbed “the driver.” Besides the driver, you also have the navigator, who is in charge of keeping the driver focused on the main goals at hand, offering direction on what to write and how to write it. The remaining group is also part of the mob, usually not directly engaged but may occasionally offer suggestions or ask questions. The individuals in these roles will regularly rotate, the navigator becomes the driver, the driver moves into the mob, and a new person previously in the mob will now navigate. The mob usually decides when to rotate, and may do it after each commit, or at specific timed intervals, for example. In my experience, 5 minute timed intervals are common. The teams I work with often use the following tool to set up and manage their mobs: https://mobti.me. Taking a look at how this tool works may also give you a better understanding of how mob programming is generally structured.
Mob programming all day
Mobbing has benefits, it can be a great idea when working on a complex architectural set up, for example, where you want your entire team to understand the foundational concepts and have experience in setting up the infrastructure. It can be great when making modifications to a design, where you can have input from someone who is more design oriented and someone more business oriented, which can cut down the time needed to fix a design issue. It can be great for ramping up a junior dev on a project. Problems arise, however, when you take several programmers, especially those with related expertise, and force them to mob all day, on every feature.
When engaged in constant mobbing sessions, I'm not given the opportunity to dig through the code individually without distractions and I'm not given the responsibility to make individual contributions. Instead, I'm constrained by the remote "mobbing" server—I can't take advantage of my crisp 4K monitor and local set-up that I've grown accustomed to over the years. My team is at the whims of the remote server that occasionally goes down, or suffers from connection issues.
Over time, constant mobbing on every issue, every day, creates a diffusion of responsibility, leading to less individual ownership of the code and less incentive to be creative yourself—it creates a reliance on the mob that decreases personal problem solving skills and discourages creativity and curiosity.
Personally, I learn much faster by being alone with the codebase and struggling with the solution myself—using tools like pairing only when required, if I get stuck on a problem for too long or need extra input, for example. Having to mob constantly isn't a permanent solution for situations like this, and instead leads to Zoom fatigue, only causing further frustration.
Mobbing certainly has benefits, like I mentioned earlier, but it's a tool, and just like any other tool, it has a time and place to be used. When mobbing is turned into a golden hammer, and everything becomes a nail, is when mobbing stops being an effective tool. All-day mobbing becomes the new paradigm—the standard way to solve issues—rather than just another tool in our belts. It's just assumed that every problem can be solved by the mob, and mobbing is the quintessential way of delivering code. This couldn't be further from the truth, however. The reality is that the majority of software teams deploy the currently accepted, tried and tested methods of creating software: individual focused work (sometimes referred to as "flow"), occasionally pairing or mobbing, code reviews, and open communication. When paired with remote and asynchronous work (which has become commonplace since 2019) we have a developer experience that allows the individual to contribute meaningful, creative and thoughtful code while still having the luxury to use whatever tools necessary to finish the job at their own convenience, at the pace they find comfortable and, most of all, without the constant distractions of an all-day mob.
And it's the constant distraction of the all-day mob that is one of its greatest downfalls. Having to rotate every 5 minutes for 1.5 hour periods, for example, is quite draining. The context switching leads to Zoom fatigue much faster, and can prevent an individual from doing focused work. While you are driving (i.e. actively writing code) you are at the whims of the navigator who dictates what you should do and how you should do it. The navigator is constantly derailing your train of thought with suggestions, opinions, and questions. While you are navigating, you are giving commands to another user, who from my personal experience, usually already knows what they should be doing. While in a non-active mob role (i.e. neither driving nor navigating) you are essentially just watching someone else work—it's a very disengaging position to be in. The situation is made worse when the work at hand isn't particularly engaging to begin with—when it's work that absolutely doesn't need 3 engineers to work on at the same time. Bug tickets, or data entry work, for example. I've personally come into situations like this many times, where the mob is needlessly drudging through a bug ticket or data fix only because it's "just the way we work" irrespective of the fact that it's wasting time and resources. That’s not to say that this setup always leads to a terrible developer experience, the point I’m trying to drive home is that mobbing has a time and place. It’s up to the team to decide what is an acceptable time to mob, what is an acceptable issue to work on, and who can benefit the most from—or contribute the most to—the mob.
Does mobbing lead to faster delivery
One major argument I’ve heard a lot is that mobbing leads to a tighter feedback loop, and ultimately faster deployment of features. You have your entire team mobbing on the feature, so you can skip the code review. You have your entire team mobbing on the feature, so bugs are spotted more frequently and squashed. You have your entire team mobbing on the feature, so instead of spending time researching or browsing Stack Overflow, you’re more likely to have another experienced member jump in with the solution. In theory, this is what should happen. From experience, this is often not the case.
In many scenarios, it’s hard to completely eliminate the PR review process. Your client’s devs will still want to review it, or perhaps a team member couldn’t make it to the mob and they still need to review the code. Perhaps an individual in another department, or overseas, needs to review the code before it gets merged. I’ve almost never encountered a situation where the mob was able to actually skip the PR review process completely and push the code directly to staging or production.
When your entire team is mobbing on the same feature, they eventually adopt the same train of thought. Their experience with the codebase begins to converge and knowledge transfer of important concepts has already occurred. In the long run, this means that knowledge transfer and experience will only grow in the constraints of the mobbing computer—and this decreases diversity and could lead to groupthink. A feature developed by this team may actually benefit from a code review by a fresh pair of eyes—someone not as familiar with the system who can offer a unique perspective.
Mobbing is just another tool
Mob programming can be a great tool, but it should not be the default way to work. It should not be the de facto solution for all problems. Your team should discuss what it means to mob, what benefits it brings, and every individual involved should be on board with the process. These thoughts align with those of Peter Nycander, another developer who has experience with mob programming. He echoes the same sentiments—mobbing should not be something we do all the time. He does an excellent job summarizing a lot of the things I bring up here and expanding on the issues that constant mobbing can create, you can read his article here: https://dev.to/peternycander/why-you-should-not-only-do-mob-programming-4jo9.
Mobbing has benefits, but when it's used as a golden hammer and not practically applied, it leads to fatigue, frustration, and an overall worse developer experience. Mobbing should be used as a tool, not as a doctrine.
This content originally appeared on DEV Community and was authored by Attila Komaromi
Attila Komaromi | Sciencx (2021-09-17T21:58:58+00:00) All Day Mobbing Can Lead to a Poor Developer Experience. Retrieved from https://www.scien.cx/2021/09/17/all-day-mobbing-can-lead-to-a-poor-developer-experience/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.