7 Collaborative Programming
What does it mean to be part of a team? Imagine a team of players working to move the ball down the field against their opponents. Imagine one of those players trips and falls, but the play continues. What do the other players do?
The other players adapt to the new reality by shifting their field positions in order to keep the ball moving down the field.
That’s how a team behaves. When a team member goes down, the team covers for that member until they are back up on their feet.
How do we make a programming team into a team like that? How can the team cover for someone who gets sick for a week or just has a bad programming day? We collaborate! We work together so that knowledge of the whole system spreads through the team.
When Bob goes down, someone else who has recently worked with Bob can cover the hole until Bob gets back on his feet.
The old adage that two heads are better than one is the basic premise of collaborative programming. When two programmers collaborate, it is often called pair programming.1 With three or more, it goes by mob programming.2
1. Laurie Williams and Robert Kessler, Pair Programming Illuminated (Addison-Wesley, 2002).
2. Mark Pearl, Code with the Wisdom of the Crowd (Pragmatic Bookshelf, 2018).
The discipline involves two or more people working together at the same time, on the same code. Nowadays, this is typically done by using screen-sharing software. Both programmers see the same code on their screens. Both can use their mouse and keyboard to manipulate that code. Their workstations are slaved to each other either locally or remotely.
Collaboration like this is not something that should generally be done 100 percent of the time. Rather, collaboration sessions are generally brief, informal, and intermittent. The total time a team should work collaboratively depends on the maturity, skill, geography, and demographics of the team and should be somewhere in the range of 20 to 70 percent.3
3. There are teams who pair 100 percent of the time. They seem to enjoy it, and more power to them.
A collaboration session can last as little as 10 minutes or as long as an hour or two. Sessions that are shorter or longer than those limits are likely to be less than helpful. My favorite collaboration strategy is to use the Pomodoro technique.4 This technique divides time into “tomatoes” of 20 minutes or so, with short breaks in between. A collaboration session should last between one and three tomatoes.
4. Francesco Cirillo, The Pomodoro Technique (Currency Publishing, 2018).
Collaboration sessions are much shorter lived than programming tasks. Individual programmers take responsibility for particular tasks and then, from time to time, invite collaborators to help meet those responsibilities.
No one person is in charge of a collaboration session or of the code being manipulated within a session. Rather, every participant is an equal author of and contributor to the code under consideration. The programmer responsible for the task is the final arbiter should a dispute arise in the midst of a session.
In a session, all eyes are on the screen, all minds are engaged on the problem. One or two people may be seated at keyboards, but those seats can change frequently within the session. Think of the session as simultaneously being a live coding exercise and a code review.
Collaboration sessions are very intense and require a lot of mental and emotional energy. One or two hours at that level of intensity is likely all that the average programmer can tolerate before needing to break away to something less consuming.
You might worry that collaboration like this is an inefficient use of manpower, that people working independently can get more done than people working together. This does not turn out to be particularly true. Studies5 of programmers working in pairs have shown that the productivity within a pairing session drops by only about 15 percent, as opposed to the feared 50 percent. However, during that pairing session, the pair creates about 15 percent fewer defects and (more important) about 15 percent less code per feature.
5. Two such studies are “Strengthening the Case for Pair Programming” by Laurie Williams, Robert R. Kessler, Ward Cunningham, and Ron Jeffries, IEEE Software 17, no. 4 (2000), 19–25; and “The Case for Collaborative Programming” by J. T. Nosek, Communications of the ACM 41, no. 3 (1998), 105–108.
Those last two statistics imply that the structure of the code being produced is significantly better than the code that might have been produced by the programmers working alone.
I haven’t seen any studies on mobbing, but the anecdotal evidence6 is encouraging.
6. Agile Alliance, “Mob Programming: A Whole Team Approach,” AATC2017, https://www.agilealliance.org/resources/sessions/mob-programming-aatc2017/.
Seniors can collaborate with juniors. When they do, the seniors are slowed down by the juniors for the duration of the session. The juniors, on the other hand, are sped up for the rest of their lives—so it’s a good trade-off.
Seniors can collaborate with seniors; just make sure there are no weapons in the room.
Juniors can collaborate with juniors, though seniors should watch such sessions carefully. Juniors are likely to prefer to work with other juniors. If that happens too frequently, a senior should step in.
Some folks simply do not like to participate in collaborations like this. Some people work better alone. They should not be forced into collaboration sessions beyond reasonable peer pressure. Nor should they be disparaged for their preference. Often, they will be happier in a mob than in a pair.
Collaboration is a skill that takes time and patience to acquire. Don’t expect to be good at it until you’ve practiced it for many hours. However, it is a skill that is very beneficial to the team as a whole, and to each programmer who engages in it.