I spent the first half of my career building software as an individual. Initially the applications and projects I worked on were small, so there wasn’t a lot of potential for stepping on others’ toes. And collaborating with others? Why would I do that? Programming seemed a solo sport. I was content with sitting in a cube or office by myself, head down and focused on my problem.
In the 1990s, I worked in larger development teams on larger applications. My software changes not only had to work, they also had to get along well when introduced to software changes from other folks. I learned how embarrassing it is to have to utter the phrase “but it worked on my machine.”
Even though the challenge of building software was now our problem instead of just mine, my teammates and I still worked alone in cubicles most of the time. We adopted a process where we integrated our software into a common (master) source base every once in a while — perhaps once a week. Sometimes my effort to integrate the software went well. Sometimes I entered the trying state known as “merge hell,” during which I’d agonize over how to resolve conflicts between their changes and my changes.
Today, it seems silly to view the average software development project as anything but a team effort, yet countless development shops still believe the solution is to improve how we work alone.
Get TestRail FREE for 30 days!
Solo Development Today
Wiser shops admit that software should undergo quality reviews. We don’t want to let programmers integrate horribly designed code into our source repository. In the old days this meant things like code walkthroughs or Fagan inspections, where we’d get together in a room and slog through code, looking for problems. These walkthroughs could occur only after the software was produced, of course.
Today most shops use pull requests (PRs) to manage ex post facto reviews online. A developer publicizes their would-be code changes to the rest of the team as a PR, then other folks in the team can comment on the changes, which hopefully triggers follow-up improvements by the original coder. Once all parties are satisfied, the team integrates the changes into the source repository.
One of the problems with solo development: There are millions of ways to code things, and the vast majority of those ways result in code that costs more to maintain. Programmers can craft code in a manner that makes it very difficult to change or, worse, very difficult to even understand. What might make sense to me during my moments of coding might be a very bad idea or make no sense to others. It’s kind of like explaining a dream to someone else after you wake.
Good luck fixing the bad dream that is sometimes the work of a solo programmer. By the time we get to reviewing the code, we’re already feeling the pressure to move on to the next thing. We often don’t even spot some of the deeper nightmares in the code as we review. Some of the myriad bits of nightmare from the solo effort get fixed, but other problems end up getting integrated — regardless of whether we uncovered them!
Pair Programming
With pair programming, or pairing, two developers actively build a solution together. Usually those two developer heads produce a design better than that of one.
In order to ensure a solution is not just the brain fart of one blind developer leading another, experienced pair programmers seek to rotate the pair mid-task — in other words, a third party replaces one of the original pair. This pair-swapping helps promote crafting solutions that are readily understood by all developers on the team. Occasionally the third party arrives, sits down and immediately asks, “Just what were you two smoking?” At that point, before it’s too late, the newly formed pair spends time putting the software back on track to align with the team’s expectations around maintainability.
Pairing practiced with such healthy rotation can provide sufficient, active review of the code. Over time, all developers learn about and help improve all corners of the codebase.
However, the success of pair programming demands some amount of management overhead. How often do we rotate? What happens if we have odd numbers of people? How do we ensure that we switch mid-activity? What if one developer is incapable of pairing with another? What do we do about software produced by a solo developer? How much is context-switching time costing us? How do we best deal with pairs of novices? What about dominant programmers who run roughshod over their partners? We can, of course, answer these challenges, but there is a legitimate amount of management needed for the act of pairing.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Mob Programming
Mob programming, per Woody Zuill, is “all the brilliant people working on the same thing, at the same time, in the same space and on the same computer.” With everyone in the room, the software must make sense to all before we can proceed.
The solution we derive in a mob is the best that the team can hope to derive at that point in time. Some dysfunctions (e.g., type A personalities steamrolling others) can still rear their heads, but the team will likely insist on resolving the problem before moving forward, while a pair might choose to pretend the problem doesn’t exist.
People Are People
We all come to the arena of software development with our own perspectives and biases. Many of us are socially reserved and find it naturally easier to focus on programming when alone.
Many of us have never learned how to solve problems as a group. It is certainly an acquired skill, but usually the combined effort results in much greater solutions. I was surprised to discover some years ago that most modern television sitcoms are collaboratively written: A group of writers produces a script by throwing ideas to one another in a team room. It’s proven to produce far more laughs in far fewer hours.
I believe that most developers are capable of learning how to contribute in a mob programming environment. Application of strong style pairing provides a safe but strong mechanism for rapid learning and growth in a mob.
No doubt there will always be a few individuals who are incapable of any sort of collaborative work. That’s OK; there will always be teams that are completely disinterested in pairing or mobbing. But from the results I’ve seen, mob programming is, by and large, the most effective route to produce quality software. Of course, this generalization isn’t guaranteed to apply to every team.
Should We Always Mob, Then?
As a coach and someone interested in continually learning, I thrive in a mob environment. I also enjoy the social gratification that it can provide.
As one of a very large number of introverts in the software development world, however, I can only do so much mobbing or pairing. Being introverted doesn’t mean that we cannot handle group interaction; it does mean that we need solo time to recharge our internal batteries.
Additionally, exploration time can be valuable to the team, and essential for some people like myself. While I’m learning about a new technique or concept, I need the time to explore it from various angles so that I fully understand it. This mode of learning might not be something the mob wants to (or can) accommodate. As a result, I need an hour or so per day of time away from the mob to explore.
You can justify occasional pairing for similar reasons. One-on-one pairing sessions can support a more focused exploration and deeper dialogue that’s sometimes the most appropriate avenue.
Ultimately, I view solo programming, mob programming and pair programming as tools. Perhaps mobbing is your team’s primary mode of working. That shouldn’t preclude subsets of the team from working in pairs or as individuals from time to time. You’ll want to come up with guidelines around the expected outcome, of course. As with all tools, you must experiment to find the effective balance for your situation.
Article written by Jeff Langr. Jeff has spent more than half a 35-year career successfully building and delivering software using agile methods and techniques. He’s also helped countless other development teams do the same by coaching and training through his company, Langr Software Solutions, Inc.
In addition to being a contributor to Uncle Bob’s book Clean Code, Jeff is the author of five books on software development:
- Modern C++ Programming With Test-Driven Development
- Pragmatic Unit Testing
- Agile in a Flash (with Tim Ottinger)
- Agile Java
- Essential Java Style
- He is also on the technical advisory board for the Pragmatic Bookshelf.
Jeff resides in Colorado Springs, Colorado, US.
Test Automation – Anywhere, Anytime
