Here’s the science behind mob programming.

Two months ago I wrote an article about my experience with mob programming.

Many of you enjoyed the article and I’m glad that I was lucky enough to introduce new people to the concept.

Other developers — understandably —were sceptical. Some of them said that they weren’t sure about paying “three programmers to do one programmers job”, or that code would get worse as people fought between themselves over the right programming style. Finally some people just thought they wouldn’t enjoy it.

Whatever they thought, the challenge was the same. “Give me proof.” So, here it is.

The claim: Mob programming sessions improve code

Back in 2000 the University of Utah set out to see if pair programming (like mob programming but with just two people) had any benefit in terms of improving quality of code. They did this with a simple experiment. They asked two sets of programmers to solve a problem. The first set — the control group- had to solve the problem on their own and the second solved it as half of a pair. The solutions were then tested against a suite of unit tests. The results were remarkable. The pairs achieved 15% fewer failed tests and came up with a solution that had fewer lines of code.

What we know about the nature of programming is that there will be much better results in the real world and that they will be further enhanced by adding a third person. Why? Well, in the real world we deal with systems that are much more complex than an example program. There is therefore more opportunity to make mistakes and consequently more benefit for mistake preventing practices like mob programming.

Experiences of developers are also a really good indicator of whether or not mob programming improves your code. When Salvatore Zappalà described his experience with mob programming, here on medium, or David Bernstein described his on Agile Alliance, both agreed that their code was improved by mobbing.

The Claim: Mob programming will improve productivity

In a literature review, Ward Cunningham and friends reference the work of John Nosek. John did an experiment where professional programmers were asked to complete a programming challenge. Once again, there was a control group who did it alone and another group who did it as part of a pair. When they compared the time taken to complete the challenge, the pairs managed the task 40% faster than the lone programmers.

Now I know what you are saying, there is 100% more people in a pair, so the productivity increase would need to be 100% to make up for the increased headcount. For a mob, it would have to be 200% or more. But there’s evidence to suggest that in a real world mobbing scenario the benefits would be far greater than in the controlled experiment. For one thing, we know that the speed of our programming teams is dependant on far more than their ability to solve problems fast. Matt Stine realised this when he came up with his 7 wastes in software development. Turns out a lot of these wastes can be avoided by mobbing. Here’s how:

Handoffs: people can come and go in a mob, there’s no need for a handoff process.
Delays: many delays are based on programmers blocking each other — this doesn’t happen when we are working together.
Task Switching: Everyone is working on the same thing so no need to context switch, even if someone leaves the mob there is always someone contexted up to continue.
Defects: mobs lead to fewer defects in code.

One of those points really stands out to me. The idea that defects are time wasted. The amount of wasted time is larger than we often think. There’s a long process getting defects reported, scheduled and fixed. It’s far too common for development teams to speed up by writing buggy code, just for support teams to slow down.

Matt Stine wrote a fantastic guide to waste, but he missed out the biggest waste of all. That waste is the cost of wading through sh*it. In his book, clean code, Uncle Bob describes how development teams can start their project lifetimes moving at light speed, but through bad design decisions, simple fixes can go from taking hours to days to weeks. Developers working together in mobs will have more freedom to think about these decisions — as a bonus, that one programmer in your team who thinks that the SOLID principles are a bunch of tosh won’t be able to cause havoc without peer review.

The Claim: Mob programming makes you a better programmer.

The final claim I’m going to argue for is that working in a mob will make you a better programmer. What surprised me about this is the strength of agreement between people who have worked in mobs . For example Engineers in the UK Government , meltwater and individual developers like Woody Zuill all agreed that they learnt and developed faster while working as part of a mob.

Looking at the picture more broadly, Cockburn and Williams asked a bunch of students to learn ASP.NET in pairs, the results were decisive. 84% agreed with the statement “I learned Active Server Pages faster and better because I was always working with a partner.”

This is hyper important for one big reason, software development is moving on at light speed. In my last article I described just how much on the job learning we need to do as developers to keep pace.

One last thing

If you thought this article was helpful why not hit the follow button, comment with your thoughts or clap the article. Every time someone engages with my work it tells me that there is a market for me to do more. That and it makes me feel good :)