Solo Programming, Pairing, and Mobbing: Which Is Right for You?
Progamming and testing have often been thought of as individual pursuits. Headphones on, eyes focused on the monitor—this is “solo programming.” Yet today, most developers and testers find themselves in the midst of a larger team working on complex systems containing countless interactions.
Having a bunch of isolated individuals in this situation creates headaches and increases costs. One developer changes a few lines of code in the system. Another programmer later curses that something they’re working on is broken, and they can no longer understand the code. A tester might similarly find frustration that the behavior of the system keeps changing, often in unintended ways.
Pair programming is a development mode that promotes more collaboration. When pairing, you sit beside another developer or tester to design, build, and verify software. Both parties must agree on how to proceed, and both understand the solution when it’s done.
Because two heads are better than one, pairs produce higher quality solutions that cost less to maintain. But it’s still possible for a pair to go down a rathole with a bad design. Consequently, frequent pair swapping is a good practice: An individual swapping into a pair has an opportunity to prevent a troubled solution from reaching production.
Pair swapping also helps propagate knowledge across the team, which helps minimize risk, lower maintenance costs, and reduce key-person dependency.
However, pairing does demand more management overhead:
- The team must figure out who’s pairing with whom
- When swapping, a pair must spend time reviewing the work in progress
- The team requires a process for dealing with code produced without a pair
- Interpersonal issues (“I hate pairing with Cruella!”) can require intervention
A solution may be another collaborative development mode that has risen in popularity over the past several years: mob programming, or “mobbing,” where the entire team sits in a common area working collaboratively on one thing at a time.
Mobbing immediately shrinks the amount of management overhead:
- We no longer worry about who’s pairing with whom
- We spend far less time on special meetings to collaborate (iteration or sprint planning meetings, daily standups or scrums, retrospectives, etc.)
- Everyone is in the room at the same time, so we all already know what’s going on
Adhering to a few simple mobbing rules goes a long way toward creating an effective and enjoyable environment for creating and testing software. In fact, mobbing is so successful in some shops that software teams use it for most of their work. “It makes us faster,” I’ve heard a few times.
Solo programming, pairing, and mobbing—the development modes listed in order of their collaboration value—each has its place in a modern software development effort. Each is effective for certain kinds of challenges.
Not sure which to use? Start with the most collaborative mode, and back off to less collaborative practices only when you find mobbing is not working well for you. Just make sure you understand and continually improve upon how to manage the collaboration.
Jeff Langr is presenting the session A Personal History of Collaboration: Soloing, Pairing, Mobbing, Cube Farms, and Pipe Fires at the Agile + DevOps East 2018 conference, November 4–9 in Orlando, Florida.
