Some notes on Pair Programming
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.