1. 1. Styles of Development
   1. 1.1. Solo Development
   2. 1.2. Pair Programming
   3. 1.3. Mob Programming
2. 2. Mob in Practice
   1. 2.1. Tooling
   2. 2.2. Code Reviews
   3. 2.3. Motivation, Team Rapport, and Enjoyment
3. 3. Realities of Mob Programming
   1. 3.1. It Isn’t Slower
   2. 3.2. It Doesn’t Work for Everyone

Our team is completely remote. Even the people that live in the same city don’t get together. We have developed a unique way of working that helps us have communication that rivals co-located teams. It is a version of mob programming. Before I explain mobbing, let’s talk about some other ways of working.

Styles of Development

Solo Development

When I first started in software the most common method of working was solo development. It still is the most common method of working. Depending on the methodology a developer would get a specification and go off to write code. In Waterfall the developer would hibernate in their cave for a few months, come out, rub their eyes, and hand off a chunk of code. Modern methodologies have the developers syncing up more often, but the bulk of the work is still done in isolation.

One of the biggest problems with solo development is that in the time between synchronizing with other developers a solo dev can get off track. With daily syncs it can’t get too far track but it is still a tax on development. Without daily syncs it can get worse. I once had war room practically in tears when I reported that two parts of the product absolutely refused to work together. I was the first person to use the feature—we were triaging to get to code complete by this time—and the two halves were so far out of alignment that no workaround could fix it.

Pair Programming

In pair programming two developers work together. One developer is the driver and has hands on keyboard. The other developer is an observer that reviews code as it is written. The two often discuss approaches and solve problems in real time. The role switches often.

One of the benefits of pair programming comes from two sets of eyes looking at the problem. Each developer has a unique perspective and unique skills allowing for more options in solving the problem. In addition, the observer is not burdened with the ask of assembling the code and can keep an eye out for mistakes that can arise when a single developer is focused on the task. For instance, intending one thing and typing another.

Mob Programming

Mob programming takes the concept of pair programming even further. If two sets of eyes is good, more sets of eyes must be better!

Mob in Practice

At about the same time every morning the mob starts to form. Three to four developers jump on voice chat. One of the developers shares out their screen and then the mob gets to work. For the next four hours or so the team is focused on a single task.

Many times the driver is making progress fine on their own. The observers can just observe or split off into a chat about pasta. Other times the driver needs some help and the team can discuss solutions. If the driver starts straying off course or falling into an anti-pattern the observers can jump in.

Observers are watching the code that is being written, thinking about the problem, and keeping the driver motivated. The observers are also available as a reference either from memory or being able to look up reference docs quickly without needing the driver to switch contexts.

Tooling

We use Google Hangouts for voice communication and Teamviewer for screen sharing. Teamviewer has a feature where participants can click on the screen and the presenter can see which is important for pointing out lines of code. Teamviewer’s voice capabilities weren’t as good as Hangouts.

We experimented with various tools, including those that allowed multiple developers to write the same code at the same time. They just didn’t work well.

Code Reviews

Our code-review guidelines require at least 3-sets of eyes in order to merge: the author and two others. Mob programming allows us to get those eyes as the code is being written. There is usually a code review performed as the code moves from a mob branch to a feature branch or to master but those are mainly to make sure nothing was missed as a group. It’s unlikely that any significant changes in direction need to be made at this point.

Motivation, Team Rapport, and Enjoyment

Everyone has good days and bad days. Sometimes you get up and you just can’t get your brain in gear. You stare at an empty IDE and can’t get past public static void main() {}. When you’re in a mob, you can let someone else drive. You can be an observer. On those days when you think, “I can get away without a test here,” you have a team member encouraging you to write it, or willing to take over and write it themselves. The mob works at the level of the strongest individual for that day, lifting others up to their level.

When a team is communicating everyday for hours at a time them team gels more quickly. Companies exert effort to have team-building exercises to help everyone know each other, why not a team-building exercise that involves writing production code. My team communicates more than any other team I’ve been on–even teams in open workspaces sitting 4 feet from each other–and the cohesion shows. Everyone on the team is familiar with all aspects of the code so there are no silos of information.

Writing code in a mob is just more fun. It becomes a social exercise. In an experiment we went back to solo development to see if we were faster (read on to find the answer to that) and what we found was, faster or not, people had much more fun working together.

Realities of Mob Programming

It Isn’t Slower

In the lifecycle of code, only a small part of the cost is in the initial writing of code. The majority of costs comes from bug fixing, maintenance, change requests, and the like. Code written in a mob rarely needs to be rewritten when developers diverge from each other. Code written in a mob tends to have fewer bugs. Code written in a mob has better design.

When we did our solo experiment we noticed that while the initial code was written faster—of course, we could generate up to 4x the lines of code than mobbing—overall time took longer as developers had to take time to do code reviews, respond to code review feedback, and fix bugs. The code tended to vary wildly in quality and design, and broad knowledge of the code was lost. We were faster as a group.

There are times when we split the mob for speed. Spikes are a good example; we each tackle an potential solution—solo or in pairs—and report back. The code is then re-implemented as a mob with full quality. Tasks such as filling out logging or writing repetitive tests can be broken up since the core design has been decided and all that’s left is filling out code.

It Doesn’t Work for Everyone

If there is one pre-requisite for mob programming I would have to say that there needs to be a lack of ego among the developers. Mob programming can’t be a contest of “I’m right” or else work won’t be done. My team respects each other, is willing to discuss options, and is willing to be wrong. We all have the view that you can learn something from anyone. By putting the product first and ego last it is possible to work together.

Of course different personality types can perform better or worse in mob. If you are someone who has trouble communicating with people and prefer to talk to machines it may be difficult to adapt to the social nature of mob programming. I have varying levels of social skills depending on how hard I’m thinking; when I am deep in thought socials skills are paged out and my responses can be short and lacking empathy. My coworkers know this and give me leeway. Usually, though, the cognitive load is spread across the mob so deep thought generally isn’t required.

Another aspect that can be tricky to manage is different types of thinkers. I’ve found that there are some people that prefer to see deep and narrow on a problem and some that prefer to see shallow and wide. Some want to know the whole picture while others can work in the abstract and fill in details as needed. Sometimes this difference in styles will clash with one side screaming “get on with it!” and the other side screaming “I don’t have enough information!”

I’ll explore some of these issues with more detail in a later post.