There are some news items from the past year that deserve a second chance. Here we have one such - you will have heard of pair programming when two programmers team up to work on the same problem. Now there is mob programming which is pair programming raised to the power of however many people you can throw at it. But does it work?

(2019-07-29)

Many hands make light work (and I always thought it was photons) is a well-known saying, but does it apply to programming? Pair programming is probably the first stage in applying the idea. Two programmers looking at the same problem and looking at the same code that is being created does seem to have advantages. The problem is that while some programmers really like working in pairs, others find it oppressive and judgmental. I guess a lot depends on the pair.

Mob programming is relatively new, but it is just as simple an idea as pair programming. The big difference is that the whole team work on the same problem and the same code.

A new research paper attempts to find out if it really is a good way to code:

"The term Mob Programming was first coined in the Extreme Programming (XP) community in 2003 by Moses Hohman to describe their practice of code refactoring in a group of more than two. The term largely fell into obscurity until Woody Zuill began popularizing it again from 2013. It was then that Woody began speaking at developer conferences about how his commercial development team of about 8 members was "mobbing" fulltime and the successes they were seeing."

The study was of an established company with around 50 development teams. One team had been using mobbing for 2 years at another company and 18 months at the current one.

"The team has nine members, six Developers and one Development Lead, one Tester and one Business Analyst (BA). Apart from one new graduate, the team is quite experienced in Agile practices and coding with development experience in the range 4-18 years. When the team was formed the members were new to each other as a team"

It is important to note that the team was already into agile programming and the Kanban approach in particular. They also made use of Test Driven Development.

But how do you actually mob:

"The mobbing sessions initially took place in a meeting room separate from the team’s usual workplace. The specific meeting room depended on availability, but each had a large monitor for use in mobbing. Team members brought their own keyboards and a single laptop for use while mobbing. Later, a dedicated area close to the team’s usual workspace was set up with a dedicated mobbing machine. In this area there was a 60” screen with a central desk which everyone sat around, as well as some partitions to reduce ambient noise"

So just one typist and one screen to look at. The typist was changed every 10 minutes.

Was it beneficial?

There were some fairly obvious changes to the team's behavior brought about by this approach. The first is that work items tended to be completed before moving on to the next. The team gained a joint ownership of the code. The team members gained a common approach to coding style and design. Tool use became standardized and the team gained a knowledge of the entire code base because there were no specialists. There were many other smaller gains.

The disadvantages of the approach can also be seen as longer term advantages. For example, code production was slowed down by team members who didn't know the area of code being worked on, but of course bringing them up to speed is an investment for the future.

It seems that there are the usual problems of interpersonal relationships and how best to utilize different people. It also seemed difficult to get the physical setup correct.

"The size of the mobbing team that emerged as being most effective with the case team was mobs of 3-4 people. When forming mobs larger than 4 often people in the mob would selfexit, feeling they were not contributing much. The trade-off between increased quality and the reduced pace of larger mob teams was often perceived not worth it unless complex parts of the code base were being worked on."

Overall the conclusion is positive:

"Overall Mob Programming in the case team has been positive, has become the usual way of working, and has shown promising potential long-term benefits. A preliminary online survey of 82 Mob Programming practitioners around the world shows general alignment with the case team’s experience and perceptions."

It is however clear that we could do with more research on the idea. Programming by committee might be prone to producing a camel rather than a horse, to invert a well known saying. The current study concentrated on how the team perceived its work rather than any measure of quality or speed of the work. However it seems to be it might be worth a try.

More Information

Leveraging the Mob Mentality: An Experience Report on Mob Programming

Jim Buchan and Mark Pearl Auckland University of Technology

Related Articles

Code with the Wisdom of the Crowd (Book Watch) 

Happy Programmers Produce Better Apps

Software Development Metrics 

Who’s Afraid of eXtreme Programming

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info