Metaphysical Developer

Some notes on Pair Programming

Posted in Software Development by Daniel Ribeiro on June 9, 2009

Pair Programming is a technique where two developers work on the same piece of code at the same time. Popularized by Extreme Programming, it had been applied long before.

One team that applies it consistently can achieve several benefits, such as:

  • Reducing the risk of Overengineering: one person is more likely to over engineer solutions when left alone, than when having a partner to keep you grounded on the problem at hand.
  • Reducing bugs: a partner reading the code is more likely to catch bugs than a the person coding, who is usually focused on the current line of code, and not on the overall context.
  • Improving Quality of Code: refactorings are easier to accomplish safely when one person is not focused on actually performing the refactoring and therefore can focus on ensuring the step is safe and checking for further refactoring opportunities. Also, the methods, modules, class names, functions and variables names are readable by at least two people’s standards.
  • Knowledge Sharing: this is one of the biggest benefits of Pair Programming because when developers are pairing, they share several kinds of knowledge:
    • Business Knowledge: even if not doing DDD, the developers communicate about the problem on a business level, what concepts are important, the business rules, and so on.
    • Technical Knowledge: such as frameworks, object libraries, platforms, ORM frameworks, databases, programming languages and tools that are being used, or could be used, on the project.
    • Theory Knowledge: a software project is not just solving business rules. From time to time, more abstract concepts are needed to solve a problem, and developers can teach each other about concepts such as concurrent programming, aspect oriented programming, design patterns, architectural patterns, graph theory, boolean algebra, security and cryptography, regular expressions and formal languages, problem complexity, software design
    • Project Knowledge: how the project works, how it is deployed, how to access the subversion (or any other SCM), how and which methodologies are applied, how bugs are tracked, and so on. It also includes the knowledge of the history of project decisions such as: why was this library used instead of that other one, why this algorithm was selected, why this architecture is being used, which other frameworks were evaluated…

    In order to allow the knowledge to be shared among all participants, it is vital that pairs are constantly changed within a team. How often if very dependent on the size of the team, the features being tackled, and the team’s willingness to change it more or less often. All these types of knowledge sharing brings some other nice advantages: it gives the project less risk, as no single part of the code can only be changed by only one person (specially useful when this one person would be vacation, sick in a hospital, or leaves the project). Also, gives more confidence for the team to employ Collective Code Ownership, it allows the team to be more productive over time, as less of the basics is needed to be explained and more pairs can tackle a issue where only a specialist would be able to otherwise, and finally the team as a whole can estimate better the size of features to be implemented (let it be story cards, tasks, or old-fashioned use cases), as everyone is more aware of the code base and the difficulty of problems to be tacked.

Other benefits of pair programming (an in-depth analysis can be found here paper) include: improved morale, fewer interruptions, more team focus and higher productivity. It is also important to note that a team cannot pair program all day, as people usually have other tasks to attend, such as meeting’s, training, reading and responding emails, drink coffee.

This technique can be hard to actually apply, as many developers are not used to pairing, managers are afraid of it costing more (two people working on the same machine can never be more productive) and not everyone work well with such constant peer review and collaboration. Agile Methodologies value individuals and interactions over processes and tools, and this is quite critical when employing Pair Programming, because these difficulties (which may exist in varying degrees) can only be surpassed as long as the team (including managers) is willing to overcome it. Implementing it incrementally (maybe only a few hours a day, and building it up and the team sees the benefits) can ease the resistance, and the team can get experience with it while incrementally discovering impediments of pairing more often. Also, applying Coding Standards first can diminish the occurrences of pairs fighting about minor issues such as whether to use underscore or camel case. Also, if a team struggles in the beginning, mostly managing who codes and who observes, the variant Ping Pong Pair Programming can be easier to begin with. However, it implies Test Driven Development, which can be tricky to begin if the team doesn’t do it already.

Pair programming is a great technique, one that is usually overlooked even by agile teams (as Rachel Davies was able to see on some projects she coached). But with so many potential benefits, it is always worth giving it a shot.

Tagged with: , , , ,

4 Responses

Subscribe to comments with RSS.

  1. Kevin E. Schlabach said, on June 10, 2009 at 2:52 pm

    A lot of people do not understand the importance of changing partners. I would add that this is required for pairing to be successful for multiple reasons (you only hint at it).

    The frequency of switching should be at least 2 times per week. (If you can’t do this, then your stories might be too large.) Those that subscribe to “promiscious pairing” (a concept that won Arlo Banshee the Gordon Pask award several years ago) believe that this rotation should be every few hours.

    • danrbr said, on June 10, 2009 at 7:07 pm

      Good point, I edited to make sure everyone get’s that changing partners is very important. Of course, people will come up with several other types of dificulties, such as: teams with only two people, teams with odd number of contributors, and so on. I did not mention those in order not to divert too much from the point. But teams will have to learn the impedments, and learn to remove it (hire more peope, or just realize that people may not have to pair all day long). Some answers such questions will not even be on the books (let it be XP’s, Scrum’s, Lean’s, or general agile books, or even agile discussion groups) and will have to be learned and crafted in order to adapt to the reality. But the important thing is to tackle the issue. Pair Programming is not easy, but it pays the effort you put into it.

  2. ferrisoxide said, on June 10, 2009 at 6:33 pm

    Good post.. as with Uncle Bob’s recent comments, with the rush to agile (read “Scrum”) we’ve forgotten about the key techniques from early agile that worked. Good to see the emphasis shift back from project management and on to the day to day practices of getting good code written.

    • danrbr said, on June 10, 2009 at 6:57 pm

      Very good point. Folwer discussed that The scrum community needs to redouble its efforts to ensure that people understand the importance of strong technical practices on his brilliant FlaccidScrum article. Rachel Davies had a whole presentation showing that most teams use mashups, and do apply technical practices, but a few practices are not as popular.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: