Over the past ten years, I worked with over a hundred development teams and they all had one common characteristic: they typically didn’t use pair programming as a technique to deliver software. Some teams talked about pair programming and liked the idea of it, but for some reason(s) they still didn’t pair. This raises the question so why won’t they pair? In my experience there are many obstacles to pair programming and collaboration. Many teams cooperate very well but don’t actually collaborate. Collaboration is a key aspect of pair programming, as it trust.
Pair programming is a technique used in software development where two programmers share one workstation, with one developer called the driver and the other is known as the navigator or observer. The pair take turns using one keyboard to write code and tests. The two developers take turns at the keyboard, giving each person an opportunity to consider the design and appropriate implementation. The pair benefits from the exchange of ideas and typically writes more efficient code.
The concept of pair programming is rather straightforward and has been in practice since the early days of eXtreme Programming (XP), around the late 1990’s. In my experience is remains one of the least used technique of XP. Given the popularity of agile practices and XP it begs the question why. My observation is that there are many obstacles to pairing.
Let’s start at the organization level. Many managers feel that when developers pair they are paying for two developers and only getting the productivity of one. This can be true when teams begin pairing, however within a short time not only do pairs deliver more functionality faster, often with less code, the quality is often much improved. Pair programing helps solve problems in code before they reach testing, much less production.
But the organizational challenges don’t stop here. There are considerations of the physical environment. Today’s developer often occupies a cubical with limited seating space. Pairing requires at least six feet of open table space for two people to sit along side one another. Some organizations don’t have proper hardware for pairing, such as a wireless keyboard, wireless mouse, and at least two 21” monitors. In the case of monitors, bigger really is better.
The organizational challenges continue from the physical equipment to how developers are rated for recognition, raises and promotions. If an organization stack ranks their employees, the chance of developers learning to pair effectively is severely hampered. In many cases, the developer wants to be seen as the super hero thereby raising their rank above their peers. Performance reviews are another blocker. Few companies recognize teamwork as a valued skill and instead look for the ‘super hero’ who can come in to save the day during a crisis. Further, organizations that consistently work in a tactical fire-fighting mode will struggle to see the value that comes from pairing where developers share knowledge of technical and domain expertise.
If your team is reticent to try pair programming, the good news is there are several published examples where pairing is built into the culture. One example is Menlo Innovations where they require all developers to pair each day. Pair programming is a condition of employment for them. While that might not be the best approach for everyone, it can work.
One of the key essentials to getting the developers to pair is a high safety factor. At the end of the day, most developers fear being discovered as less competent as they appear to be. Some would call it an example of imposter syndrome. Imposter syndrome is generally seen as a condition where you have self-doubt about your capabilities that you have convinced others that you possess.
Some people will argue that code reviews are sufficient and have ‘worked’ for them for years. The trouble with code reviews is that they happen once the code is written, often tested and ready to ship. If a problem is found, much of the time coding was wasted and it has to be reworked and re-tested, only to be reviewed again. Unfortunately this happens all too often with code reviews. Or worse, developers engage in a debate over whose technique is best. In this case either the senior most person forces the change on the developer or the loudest voice in the room wins. Both circumstances destroy trust in the team.
There are many arguments that developers pose when asked to try pair programming. The arguments can start with the expression that ‘I can get it done faster if I do it myself’ or ‘there isn’t any value to pairing with a peer as I won’t learn anything from them’ or simply ‘I tried it and I didn’t find it useful’. While all of these statements may be true, it may also be true that they simply don’t feel secure programming in the presence of another person.
The fundamental challenge is creating an environment where people feel safe to learn, make mistakes, fail faster, and continually improve their skills. Some people are afraid of failing because there are punishments for failing. An organization that punishes people for failing is unlikely to encourage experimentation and growth of their staff.
Often times, people are put together on a team and never really get to know one another as people. If you have a team that doesn’t spend any social time together this may be the best starting place. Take the team on a social outing, lunch, happy hour or any other activity that they would like to experience together. Encourage them to have lunch together, in or out of the office. It helps if they are being treated to lunch or an outing to avoid any concerns over costs. It make take a little courage to ask the company to fund such activity so be prepared to pay for it yourself, if necessary.
Creating a safe environment for people to learn can be a challenge in many organizations. Once you create a proper setting for pairing, with a table six feet or longer and 2 comfortable chairs, then the proper monitor, keyboard, and mouse is required. If this is the first time you are setting up a pairing workstation, consider using a small meeting space with little else in the room other than a whiteboard. Developers enjoy sketching out designs and logic on a board before they actually write the code. Now you have a proper physical space.
The next challenge is to provide the developers with an easy opportunity to pair. For example, ask one of the senior developers to pair with a junior developer or someone new to the team to work on any story. In any experiment, each individual should be given the option to try pairing as a practice. Forcing developers to pair generally will not result in any of the desired benefits.
Another technique that I have used with good result is to hire a consultant with a know reputation as a strong developer. The engagement can be short; as little as 2 weeks can make a significant impact. Let the developers know that the consultant is available for them to have 1:1 coding sessions and suggest they sign up for 1-hour time slots. You can suggest they work on their current assignment or allow the consultant to share a few practice examples. Another benefit of having the team work with a respected consultant is the consultant may also encourage other good technical practices such as TDD.
When setting up an experiment for the team to try a new technique always ask for anonymous feedback from the team on how any experiments including pair programming worked for them. Try to let them discover what they need to do in order to become confident in working together, pairing on and off with different people. It is not unusual for it to take several attempts with any new technical practice before the people feel comfortable using the practice.
There are many ways to encourage pair programming outside of the office, where there is less concern for their individual stature within the team. Code camps and coding dojos provide a welcoming environment where most people are learners and share their experience as well. A keen observer will be able to identify the person on the team most likely to experiment with any new technique. Talk with that person 1:1 to encourage them to build on their technical skills and provide them with an opportunity for it to happen.
The object is to get one or more of the developers to find value in pair programming. No matter the outcome of any experimenting with pair programming, the leader/manager should be supportive of the team and continue to encourage each team member’s personal development.
As the leader of a group with low safety, it may be advisable to start with showing the team a video of people pairing, or encourage them to read a book on pair programming. Laurie Williams co-authored a book with Robert Kessler titled Pair Programming Illuminated. The book shares several examples of types of pairing, including personal examples of what works and what doesn’t work. Another option is to use the web. A quick search on the web will results in a wide range of tutorials, videos and articles on pair programming.
If your attempts to encourage pair programming are not successful or you are looking for another opportunity for your team to collaborate, consider setting up a mobbing session for the team. Mob programming is gaining popularity in many organizations. One of the side benefits of mobbing is that everyone participates in the design and coding while each person takes a turn typing on the one, shared keyboard. Mob programming can help create a better sense of shared responsibility within the team and help to improve team member relationships and trust. As with any new technique, it takes practice for the team to be comfortable with it. In time, as the team begins building more trust with one another, they will be more likely to try other new techniques and that can create a better way for them to work together.
Once the team starts to accept pair programming continue to encourage them to experiment with other technical practices. Be sure to celebrate the successes and the failures, as they are all learning opportunities.
About the Author
Linda Cook, a recognized technology leader and Agile Transformation expert, is committed to helping organizations achieve their strategic goals. With over twenty years of experience as an IT executive, Linda offers a unique blend of leadership, innovation, and vision which allows her to tackle the most complex organizational challenges. She currently leads a Lean/Agile consulting practice for Project Cooks, LLC.
Formerly an Agile Program Leader at PayPal, Linda managed the company’s largest IT initiative with over five hundred staff across fifty-seven teams located in four countries. Prior to holding this position, Linda led several Llean/Agile transformations for large organizations, including Fortune 100 companies, and generated team performance improvements up to 250 percent. She has also managed several large-scale system development efforts and led multiple Agile programs through successful ISO 9001-2008 audits and CMMI appraisals. You can reach Linda at linda@projectcooks.com or visit www.projectcooks.com for more information.
