Pair Programming? Sure. Pair Shoveling? Not so much…
I’ve been reading about Agile methodologies and the SCRUM approach to software development recently, as I prepare to institutionalize the practice throughout my organization.
One of the methods highly espoused by some Agile aficionados is “pair programming.” In this method, two developers literally share a single computer and take turns on the keyboard. The “observing” developer provides immediate feedback to the typist should anything appear fuzzy in the logic being written, while also considering the bigger picture solution. After 30 minutes or so, the roles switch, and the keyboard gets handed over.
In theory, some amount of logical errors (bugs) are avoided when the program survives the scrutiny of two independent minds. Pairs may be changed around regularly to avoid developers getting into a groove and thus losing the “independent minds” benefit.
Some developers bristle at the notion of letting another developer into their brain space so intimately, while others have tried it and swear by it. Some of the studies indicate a slow-down in initial coding but a significant enough reduction in bugs and other long-term maintenance / rework to more than justify the change.
Personally, my jury is out on the whole concept until I get more experience with it – actually see it in my own teams and hear from my developers. It seems like a good mechanism for continuous sanity checks, but I know there are minds that like to solve problems in private before sharing ideas with others.
However, I did see something recently that requires no more data, no more empirical studies, for me to know it’s a bad idea: Pair Shoveling.
I had the good fortune of spending the holiday break with my family on a sunny beach in the tropics. Every couple of days, the resort would comb the beach for the mounds of seaweed that the constant, pounding waves deliver, non-stop, to the shore. The team consisted of a tractor with driver, and two men tasked with digging a pit. The tractor combed the debris and continually dumped the contents into the pit. The shovel-wielding job consisted of digging out a larger and larger hole in which to bury the debris – staying ahead of the tractor’s endless onslaught.
The men shoveling really did not work well as a team, and in fact their productivity was half of what it should be. This is because, perhaps in a failed attempt to be Agile, they were sharing a single shovel. One man shoveled while the other watched for 20 minutes, then they switched. All the while, the tractor kept on delivering more and more debris to be buried. Repeatedly, the shoveling team would realize that the pit must be expanded, which meant displacing again the sand piled up around the current borders of the pit.
I won’t pretend to understand the economics, politics or logistics that led to this job sharing arrangement, and mean no disrespect to the two men trying to do honest work with inadequate equipment. My comparison to pair programming is, of course, tongue-in-cheek. However, watching the spectacle with a SCRUM text in hand, I couldn’t help but reflect on the unorthodox approaches we try in pursuit of excellence in the software industry. The shoveling team I observed were not helping each other dig a sufficient pit, they were merely relieving each other. They didn’t stave off rework, as the pit had to be expanded at least five times while I watched. They were not improving methods or finding more innovative ways to shovel. They were just taking turns shoveling.
I’ve read that pair programming really has little benefit on repetitive, already “solved” development activities that require little innovation and limited diligence. Shoveling. The best benefits are realized when charting new courses, solving new problems, etc., when the first thought of a single developer is unlikely to be the best answer.
We can safely use a mix of pair programming and singles in many projects. Not every project is 100% ground-breaking such that some of the routine work can be done solo, probably by newer team members coming up to speed.
We can also raise the awareness within the team that when you find yourself “pair shoveling,” partnering on something that is not benefitting from collaboration, it’s time to make a change:
- Break up the pair, and power through the work individually,
- Move on to a different challenge, if the shoveling deadlines can still be met (that tractor never stops!),
- Turn some of the problem-solving energy to automating the mundane coding itself – if it’s not challenging, it should be ready to automate.
I don’t know if “Pair Shoveling” will make it into the Agile lexicon, but for me, it will serve as a reminder to use the correct tool (and correct number of tools), for the job at hand.