At Mavenlink, we develop software in an unusual way. Every morning, after a cup of coffee and the usual standup, we gather around an iMac at one of our standing desks and discuss the previous day's work.
What worked and what didn't? What were the "interestings" from the day: challenges overcome or nuggets of knowledge gained that the whole team should know about? How should we divide up the work for today?
Division of labor is a concern for all businesses, but this last question is simplified through our use of a development technique called "pair programming." Pair programming is an agile software development technique that places two software engineers per computer. The engineers take turns writing code and discussing the problems at hand.
Ultimately, this approach means two people discussing problems, two people vetting code, two people considering bugs and two people carrying their experiences forward to share with the rest of the team.
At first glance, this approach could seem like a redundant use of our developers' time. Wouldn't it be more efficient to encourage everyone to work on something different? At first, perhaps it would be.
But for many reasons, over the lifetime of a company, we do not believe this to be the case.
According to “The Costs and Benefits of Pair Programming,” research conducted by Alistair Cockburn and Laurie Williams, for a development-time cost of about 15 percent, pair programming improves design quality, reduces defects, reduces staffing risk, enhances technical skills, improves team communications, and is considered more enjoyable at statistically significant levels.
In our experience, pair programming results in higher quality code with fewer bugs. Ensuring that at least two people have thought through the implications of a change reduces the likelihood of surprises later. Additionally, having a second set of eyes reduces the number of silly mistakes that all programmers make from time to time.
When bugs do occur, tracking them down is easier with two people brainstorming and applying their personal experiences.
Another benefit of pair programming is added focus – and this shouldn't be underestimated. If you walk around a typical office, you’ll see people reading news, watching videos on YouTube and talking over IM. You’re unlikely to see this in our office. We’ve never explicitly forbidden such behavior because we haven't had the need.
When you're pairing, you're part of a team – right now – and stopping both of your progress to read the news just feels ridiculous. So we have a lot of fun. We talk about interesting problems all day and always have someone to joke with. This might not work well for everyone, but it works remarkably well for us.
One problem with many companies' approach to software development is the prevalence of "siloing," where only one developer knows how a particular section of code works. If he or she quits, gets sick or becomes a liability, the rest of the team has no idea how to proceed without him or her. This isn't a theoretical concern; it happens all the time.
By pair programming, not only do we bring more eyeballs to any particular problem; we also ensure that we have no single point of failure.
We believe that, just as it would be crazy for us to run our site on only one server or to store your data in only one place, it would be equally crazy for us to allow only one person to know how critical pieces of our product work. By spreading this expertise and responsibility, we achieve a work environment with lower stress and fewer points of failure.
While still an uncommon practice at most companies, pair-programming is growing in popularity and is attracting the attention it deserves. At Mavenlink, we wouldn’t program any other way.
About the Author
Mr. Cantino has a Masters in Computer Science from the Georgia Institute of Technology and a B.S. in Physics from Haverford College. His academic work focused on the field of Intelligent Systems, specifically Artificial Intelligence in computer games and machine learning in web applications.