Pair Programming. Its that thing you might have been forced to do in a Software engineering class. You probably hated it. Someone probably abused using the shared mouse and keyboard thing a little too much. Someone probably had switched the cables too so that you controlled the wrong computer…
Pair Programming is one of those ideas that has become a bit of a annoyance in the software world. It just tends to leave bitter taste in people’s mouths. Some are just downright against the idea, though they have never actually tried it. Most developers are likely not able to describe the goals of Pair Programming either. Many developers will say something like:
- “Its when two programmers code together; duh!”.
- “It prevents bugs I guess?”
- “It doesn’t matter. Its a waist of time”
With that in mind, I’d like to try to re-orient and explain what Pair Programming is and what its meant to do like I was telling a 12 year old.
Pair Programming was initially introduced as a tool with in the Extreme Programming Agile framework. The official definition of pair programming from that framework is this:
Pair programming consists of two programmers sharing a single workstation (one screen, keyboard and mouse among the pair). The programmer at the keyboard is usually called the “driver”, the other, also actively involved in the programming task but focusing more on overall direction is the “navigator”; it is expected that the programmers swap roles every few minutes or so.
This great technical definition doesn’t do much to help understand what Pair Programming actually is. I usually define it as simple as:
Two programmers actively working in tandem to write code at the same workstation. One programmer writing code and one being an active observer, with roles being switched periodically.
Basically, it really amounts to two developers working on the same problem at the same time in order to, hopefully, design or code a solution better than if working apart. Generally, this would be at the same workstation with shared mouse and keyboard setups, but distributed models of sharing screens is just as good.
A key part is that both developers are actively involved. The observer isn’t just watching and being distracted by email, Slack or cat gifs. The observer should be reading the code written, looking up specifics about APIs or language specifics if there are questions, and providing input to the programmer writing code when necessary. You won’t reap any of the benefits (see below) if one person isn’t involved. It just becomes one person solving a problem again.
Basically, Pair Programming is trying to provide quick feedback by sharing knowledge early through person-to-person collaboration. Do any of those ideas sound familiar? Well they should since they map to the Agile Manifesto pretty easily (see my last post on that here).
With that in mind, instead of spending more time on definitions and semantics, lets approach this through examples and scenarios.
What Pair Programming Is NOT
- A brain-storming session. Brain-storming sessions (or even design sessions) are helpful and useful parts of the software development lifecycle, but pair programming is different than that. Pair programming is much more nitty-gritty.
- Time for an expert to “show their stuff” or prove their worth. Pair programming is an active collaboration that requires both programmers to share thoughts and listen to the other’s.
- Its not a place to endlessly discuss solutions or directions and never start working on something. While that is really tempting, remember that just like everything else with agile, at some point, you have to start somewhere.
- Time for “grunt work” code. There are always parts of solutions that need code, but are also simple and mundane. Don’t use Pair Programming when you are coding in these situations.
What Pair Programming IS
- A learning opportunity. Every pair programming sessions is a chance for ideas and knowledge to be shared. Its a chance for young developers to learn from experts and for experts to question some of their assumptions.
- Chance for early feedback. With an active observer watching every line typed by the coding, there is a great chance to spot defects as they happen; improve readability right then and there; design classes for easier maintainability.
- Time to work on the hard problems. Instead of spending hours staring at a screen wondering were to start, grab a co-worker, a screen, and start talking through some ideas and get those fingers typing.
Does Pair Programming Work?
One of the most contested issues, with Pair Programming is if it actually works. Like some of the developer responses from above, many think Pair Programming just means spending twice the resources to get the same results.
This is where some more reading really comes in handy. A simple study, but realistic in my opinion, wanted to answer just how effective Pair Programming was with a group of seniors at the university of Utah. Dr Laurie Williams, along with other early Agile leaders, assigned a set of tasks to students that were accomplished in pairs vs individually (accounting for various levels of ability shown in prior classes). What they found was:
- Total elapsed time by pairs was faster, though the developer hours were higher
- After the first assignment, the combined number of developer hours for a pair decreased (ie pairs became more effective over time)
- Total defects were less in solutions from pairs than individuals
- Nearly all paired developers reported feeling better about their solutions
All in all, that is a pretty remarkable difference. Of course, the scoffers would say “This was with students in a classroom setting. It doesn’t work in the real world”.
And.. they have some reasons. The study cited above is one of the positive studies, while other studies have mixed results. This study in particular, which focused on Java consultants, found very mixed differences on the effectiveness of Pair Programming based on experience. Another suggests that benefits are only found after a Pair has worked on problems several times before, and that those problems must truly be novel or unique. And of course, there is a lot more reading to than this. If your really interested in reading more, check out Agile Alliance and/or some Googling. I know there is WAY more material out there.
What Is My Take?
I have found Pair Programming is helpful in small bursts where a complex problem is being worked on and might potentially be a foundation for future development efforts.
What I mean, is that instead of making Pair Programming a formal endeavor, I have shorter, less intrusive sessions than what traditionally literature might advise. I’ll get with a co-worker to discuss a problem and possible solution, we will work from the same computer for a little while, come up with an approach, maybe tackle a confusing or tricky part of code, and then break for me or them to do the “grunt work” code. After most of the code is complete, we will have another brief session, and continue the pattern until we are satisfied with the solution.
There are several benefits to this approach.No one is getting bored being an observer; the driver isn’t sweating hoping to not type a bad line of code; no one has the time to “show another up”. The biggest one though, is that the “waisted” resource time with traditional Pair Programming is minimized, but the benefits of quick feedback, learning and knowledge sharing are still felt.
Have you tried Pair Programming? Tell me about your experiences (good or bad) below!
Till next time!