When we Mob, Pair or Solo Program

In 2010 it would be a rare sight to see two programmers sitting together solving a problem at Tranzact. Only in times of distress would someone shuffle in next to another team member to work through something new or challenging. I wouldn’t say we were a collection of non communicators but like many computer programmers, we were naturally more connected with our screens and our inner worlds than we were with each other or our clients. Not because we didn’t want collaboration in the office or that we didn’t want to build a great product for our client. The idea just didn’t come naturally to us and we didn’t have the skills to make it happen effectively. Today we try to take the time to learn these collaborative skills and one of our focuses has been to look at how we can code well together. We have introduced both pair and mob programming and we use them for various types of work.

Mob Programming

Martin Cronje from nReality introduced us to mob programming earlier this year. When you ‘mob’ the whole team works with a single computer and a single keyboard. Everyone contributes and takes turns typing. This 3 minute video shows a typical day of mob programming. We use the technique for things we think are best solved as a collective like:

• Learning and mastering skills together
• Transferring business knowledge
• Working through complex problems
• Working through code that may have high regression

Apparently some teams experience enough increase in value that they mob program everything. Mob programming definitively results in high quality work that is aligned to business value. The team learns frequently and deeply. There is little time spent aligning team goals because everyone is working on the same thing. For the same reason there are no key person issues. When someone goes on leave things keep going along as usual. It is much easier to build and deploy a single piece of work without a change in focus.

A lot of benefits but the cost is that input into your code base only occurs from only a single keyboard. Also its pretty intensive. For these reasons, and because we still have a way to go before we’ll focus on a single goal like a great sports team, we don’t mob program everything.

Pair Programming We typically pair program for similar reasons to the mob exercise and only distinguish the two because pair programming happens at someone’s desk while mob programming happens at our meeting table. For both we take 10min turns at the keyboard. The person typing is not allowed to go ahead with any work unless they have buy-in from someone else.

Solo Programming

We code things solo if we feel we can’t extract enough value from a pair or mob programming exercise for the type work required. Typically these tasks are well understood both from a business value and technical perspective. A developer working on a task solo will end with a functionality demo and test and a code review. We do this to inject some mob and pair programming benefits (like increased quality and consistency) into our solo programming tasks. For our team, some solo work is important as it provides a space for the more introverted of us to re-energise in our natural comfort zone and think introspectively for awhile.

In summary

Introducing more collaboration into the writing and testing of code has benefited our team in a number of ways.

We’ve managed to introduce pair and mob programming without reducing our output even though we have some technical and business knowledge gaps to fill across the team. Admittedly we solo code a large amount of our work but I think it’s quite telling that working together comes at no output cost right from the start.

Originally published at blog.gregvanberkel.com on Oct 31, 2015.