Pair programming. You may be familiar with this concept by now as it draws quite a long-standing debate in the software development world. In an article published yesterday by The Wall Street Journal, Joseph Walker positions pair programming as a way for “Computer programmers to learn tough lessons in sharing”. But that didn’t come before Jon Evans questioned whether or not pair programming was considered harmful in a tongue-in-cheek titled TechCrunch post. This prompted our VP of Engineering, Farhan Thawar, to rebut with this article. The New York Times wrote about pairing in 2009, noting for writing software, a buddy system is best. So again, here’s our two cents on the topic.
Pair Programming Works in Practice
In theory, pair programming seems like an interesting concept for development to many computer engineers and software developers alike. In practice, pair programming works by pairing two engineers with two screens, two mice, two keyboards and one computer work together to write code. Code can be written fast, can be debugged on the fly, and is mutually beneficial for both programmers as there is an exchange of knowledge for the project they are both working on. But on the flipside, the argument against pair programming claims that it can cause groupthink, a lack of creativity for the developer, or makes two great engineers ineffective when put together to program.
To dispel those arguments we must look at where pair programming has been beneficial in practice. Google’s Jeff Dean and Sanjay Ghemawat have paired together in the development of groundbreaking work like MapReduce and BigTable that powered Google’s “rise to the web’s most dominant force.” Kent Beck, a major proponent of Extreme Programming and now at Facebook, is strong advocate of pairing. He wrote the 1999 book titled “Extreme Programming Explained” where he states that software should be released quickly and improved along the way, echoed in Facebook’s mantra of “Move Fast and Break Things”.
Grockit CEO Roy Gilbert said the practice has proven a success, and his developers “continue to evangelize the method.” Pivotal Labs, a software-development shop that was bought by technology giant EMC Corp. in March, has its 175 engineers pair all day, every day. They too change partners daily in a practice called “promiscuous pairing.”
Pair Programming Pragmatically
With so many conflicting opinions on what the best practice is, it’s no wonder there’s so much commotion over this development process. But what people seem to misunderstand is that pair programming needs to be adapted in order to fulfil its purpose and to fit the needs of the developers. For example, pairing doesn’t work 100 per cent of the time, or in all situations. Nor does it work with every personality that exists on a team. Taking these things into account is how we’re able to pair effectively most of the time.
From the beginning, we pair program daily at Xtreme Labs. We’ve molded it to fit in with our process, hence why we’ve been able to make it so successful. Putting the notorious engineering egos aside, our whole team has adapted to the use of paired programming, and thrives under its use. Working in pairs to collaborate on projects, everyone from our principal engineers, to new co-ops fulfilling a work term, get to make great contributions to their assigned projects. Our team has come to understand how to use this method of development to their advantage, something that many companies who are opposed to pair programming, seem to have not figured out yet.
When pairing doesn’t work for a part of a project, then it’s not used. When someone needs privacy to email or work on something away from the eyes of their pair, email stations around the office are available at their disposal. Collaborating, which has been confused to cause groupthink in the context of pairing, helps both engineers figure out problems faster and from a new perspective. (Another side note to dispel the ‘groupthink’ argument is a ‘pair’ is two, a ‘group’ is several). As a result, developers are better able to overcome those same problems that might occur again when pairing with others later on. When a pair isn’t working out, the solution is simple: get a new one. Weekly ‘Anchor Status’ meetings provide the perfect opportunity to voice any concerns; this is also where the lead engineer of a pair can re-allocate resources based on the difficulty of a project. The initiative and responsibility given to to each pair allows them to make executive decisions on how much help they will need that week. Having a pair be able to self-direct themselves on building code for a project gives them plenty of opportunity to be innovative and creative as long as there’s a finished product of high quality in the end.
Conclusion
For us, the proof that pair programming works is in our ability to ship high-quality builds to our clients every week. Pair programming allows us to deliver features in a guaranteed period of time to our clients. Because we are able to do this, we are able to make outstanding products faster for our clients. With all the talk and attention pair programming is getting, it’s nice to see it become the mainstream way of developing. After all, two heads are better than one.
About the Author
