Pair Programming

Pair programming can be a very valuable tool but it is almost always uncomfortable at first.  A good portion of that discomfort is because pair programming pushes you to interact and learn from each other in ways that are very effective, but also require a certain amount of vulnerability.  This isn’t bad. Pretty much anything that really pushes you to be your best is going to take you outside (or at least to the edge) of your comfort zone.

This post covers some basics for teams who are starting pair programming. It is by no means exhaustive but should provide a good foundation for teams looking to avoid common pitfalls.

Mechanics of Pair Programming

Ideally, pair programming is an activity with two people sitting side by side sharing a computer and talking through the process as they create software. The ability to physically point at the screen and pass the keyboard back and forth minimizes the communication overhead with this type of programming.

The pair should pass the responsibility for driving back and forth. Sometimes it makes sense for the person who isn’t driving to have a computer in front of them. For example, they could use it to lookup the details of an API or some special syntax as it is needed. They should not be sitting there browsing Facebook and checking their email. That defeats the entire purpose of working together.

Remote Pair Programming

Sitting side by side and sharing a computer is ideal, but many teams are distributed, and you may want to pair with someone who isn’t physically in your building. Pair programming using a screen share tool can work. However, it is much more difficult to hand control back and forth. One way around this is to develop in a branch where you can easily push and pull your changes. That way both members of the pair can stay up-to-date on the code and switch back and forth between who is driving.

While many teams do pair programming with voice and screen share, video conferencing software is preferable to just talking on the phone. It is beneficial to see each other, observe body language, etc. Of course, video conferencing isn’t particularly useful if your screen is filled with the code. You’ll need a separate monitor or television screen for the video to make this work well.

There are newer tools that allow for pair programming inside the IDE. For example, Visual Studio Code and Atom are both introducing the capability for two people to work simultaneously on the same code. If you’ve ever used a Google Docs with multiple people at the same time, you will have a pretty good idea of how this looks. You can see each other’s changes in real time.

Regardless of what tool you use, make sure it is fast enough. Trying to pair program with a two-second delay is very painful. If you build your opinion of pair programming on experiences where you are trying to talk in real time while looking at a screen that is two seconds behind your pair, you are likely to conclude that it isn’t worth the effort.

Shared Ownership Of Code

One of the big goals of pair programming is to make sure that the entire team owns the entire code base. There may be sections of the code that different people are more familiar with, but proper pair programming should help make sure that knowledge about every part of the code gets disseminated throughout the team.

We Instead Of You And I

Pair programming is an activity that requires vulnerability. This is easy to remember when you are the one driving and easy to forget when you are not. Even simple things like using the word “we” instead of “you” to point out problems can go a long ways toward making the interactions less threatening. “We” also helps foster a sense of teamwork, a shared responsibility that is vital to work together effectively.

Think Out Loud

Pair programmers are working together as a team. This means you need to talk through what you are thinking as you do it. You can’t just go silent and tear through writing code, hoping that your pair can keep up. It should be a conversation with suggestions and ideas coming from both of you. Thinking out loud means you may say some things that seem rudimentary, but that is fine. You are working together to solve programming problems. The best way to do that is for both of you to know what each other is thinking as you work through it.

Shared Understanding

Both members of the pair should understand what the code is doing. If your pair is questioning whether something is correct, take the time to make sure you both agree it is right. Even if you know it is right; you can’t steamroll over them. Together you will be more effective if you both fully understand why everything works.

This may mean taking a slight detour to explain something your pair may not be familiar with. This is how you work together as a team. You are making an investment in shared understanding that will have returns well beyond your current coding session.

Spreading Knowledge

One of the benefits of pair programming is the way it spreads knowledge throughout the team. Every programmer has a few shortcuts and tricks that make them more effective. Programming together lets both members of the pair learn from each other.

When two people program together, it is very common for them both to learn each other’s favorite keyboard shortcuts and command line tricks. This may sound trivial, but it is amazing how fast these small but meaningful efficiency gains can spread through a team.

I have seen instances where a junior and senior programmer were pairing together. The junior programmer was able to learn a lot of very important lessons about structuring code from the senior member, but it worked both ways. The junior programmer was more familiar with some of the newer features of Java and was able to show the senior programmer how to make some significant improvements to the code.

Alternate Pairs

You can further spread knowledge within the team by switching up pairs on a regular basis. Ideally, you want everyone to have a chance to program with every other team member. Switching up the pairs for each story can be a good strategy.

In effective teams, this tends to happen naturally. If Bob is the expert on Spring Batch and a new story is coming up that will require Spring Batch expertise, Alice may ask if she can work on the story with Bob so she can learn more about it. Teams that have worked like this for even a few months see significant efficiency gains as new expertise and best practices make its way rapidly from team member to team member.

Is Pair Programming Efficient?

When I mention pair programming to management, their first concerned is that a team of eight people working in pairs will only output half as much code. This makes sense if programming is mostly about typing, but it isn’t. Most of the effort in programming is spent thinking. One of the best ways to solve thinking problems is to talk through it with someone else. This is exactly what pair programming does. The time spent typing is insignificant.

That isn’t to say you can’t be inefficient in pair programming. I’ve heard horror stories of developers pairing with someone who simply played with their phone whenever they weren’t at the keyboard. On the other hand, when the developers are both engaged, it is usually a very satisfying and efficient way to work. Often developers comment that it is significantly more intense than programming alone because working with someone else keeps the work focused and moving along.

Take Breaks

When two people are intensely working together it can be easy to skip breaks. Don’t do this. Don’t skip lunch because you think you’ve almost solved a tricky problem together. Getting away from the work for a few minutes gives your brain a chance to solve problems in the subconscious.

Both members of the pair should take breaks at the same time. If both members are comfortable saying, “I think we should take a break now” then they can be done on an ad-hoc basis. With people new to pair programming, it can be better to decide when you are going to take a break up front. Breaks are essential for making progress and if there is a chance that neither person will be comfortable suggesting a break, then determine when you are going to break before you begin programming.


Be aware of the fact that you are going to be working in close proximity to someone and be considerate. You may want to save garlic for days when you aren’t going to be pair programming. Heavy perfume or cologne that smells great to you may give your pair a headache so be thoughtful.

I once did a phone and screen share interview with a developer who was physically at my client’s office. The guy seemed to know his stuff, but after the interview, my clients who were in the office with him didn’t seem very impressed. They weren’t exactly forthcoming because no one wanted to just come out and say that they weren’t comfortable working next to this guy. I don’t know exactly what the issue was, but they threw the keyboard away after he was done using it for the interview.

What is Agile?

Many things get called Agile—especially by people who are selling something. Agile is defined in the Agile Manifesto. The Manifesto makes it clear that Agile isn’t a methodology. It isn’t a specific way of doing software development. It isn’t a framework or a process. In fact, most of the things that are marketed as Agile tend to miss the point of what Agile actually is.

Agile is a set of values and principles.

Much of the discussion around Agile has to do with following different practices, using various methodologies, and even developing with specific tools. For example, while a team may find that having a daily standup is helpful, the standup is only “Agile” to the extent that it is the result of a team following the Agile principles and values.

When you understand this, it is easy to see that Agile is really a collection of beliefs that teams can use for making decisions about how to do the work of developing software. While this means the term Agile gets subjected to a great deal of abuse when people claim that this or that is the way to be Agile, it also means that if you truly understand what Agile is, it is surprisingly flexible. Agile doesn’t make decisions for you. Instead, it gives a foundation for teams to make decisions that result in better software development.

Agile Manifesto

The Agile Manifesto is only 68 words and very simply says that the signers have found that they can develop software better by valuing the items on the left side of the list more than the items on the right side. Below is the Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Agile Principles

In addition to the values of the Manifesto there are 12 principles that support the values. Once again the principles are very general and are less about telling you what to do than they are about giving you the ability to make a good decision in a particular situation.

The principles are:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile Decisions

Since Agile is a collection of values and principles, its real worth is in giving people a common foundation for making decisions about the best way to develop software. For example, consider a new project that is in discussions on how to get the requirements from the business owner. The suggested approach is to require that the business owner write down all the requirements and sign off on them before beginning the work. A team that is following Agile would say:

“While that might work, isn’t that inconsistent with our belief that we should value customer collaboration over contract negotiation? And doesn’t it violate our principle that says the developers should be working with the business owners every day? How can we make this decision in a way that is consistent with our values and the principles we follow?”

Or consider a developer who is working on implementing a feature for the business owner. The developer realizes he needs a database to make the feature work. The first idea that comes to mind is to stop work on the feature and build out a robust database layer that will handle the needs of the feature and provide support for other development that will be needed later. If the developer believes in the Agile values and is trying to follow Agile principles, they would think:

“But building out this layer means I will have to delay delivering what the customer can see as valuable software they can use. If I can find a way to build just what is necessary to deliver this feature, it will better align with my principles.”

When you have a team that is following Agile they will be making hundreds of decisions each week in the way described above. That is what it means to be Agile. Making each decision based on the principles and values that the team has decided to follow.

Being Agile

The decision making process matters. You can’t try to short-circuit things by taking decisions made by another team and just blindly doing what they decided to do. Another team may make decisions based on the Agile principles and values and end up with a particular way of doing their work. Simply trying to mimic another team’s actions and practices won’t make your team Agile.

After World War II Melanesian islanders were observed trying to bring cargo planes and their supplies from the sky by mimicking the practices they had seen performed during the war. This included clearing the forest to make a landing strip complete with full size planes made out of straw. They also created structures that mimicked a control tower out of bamboo and had someone sit in it wearing headphones fashioned from coconuts.

It is easy to fall into a similar type of cargo cult mentality when it comes to Agile. The things that are easy to notice in a highly functional Agile team are the practices they are using. But the practices a team uses is the result of following Agile principles and values. It is less important what practice a team happens to be using than why they are using it. In fact, as time goes by, a good Agile team is probably going to change and refine what practices they use.

A team might start with SCRUM and later find that Kanban is a better fit for delivering value to their customers. A team might begin standing up in a daily meeting and later decide it works better for everyone to stay sitting down. Another team might start out using Planning Poker to estimate story size and later do away with story points and simply split stories to where they are somewhere in the same range.

That isn’t to say it is useless to look at practices being used by teams that are performing well, but you can’t go looking for practices to make you Agile. Your principles and values are what will make you Agile. You have to look for practices that support your principles and values. The way you select your practices is what determines whether you are being Agile or not. If a practice is being selected because it looks like a good way to follow Agile principles, it is probably a good place to start. The same practice can work poorly for a team if it is selected for the wrong reason.

So what is Agile?

Agile is a set of values and principles.

How does a team become Agile?

They make their decisions based on Agile values and principles.

The decision-making process is how a team becomes Agile. The values and principles have enough flexibility to allow teams in a wide variety of organizations to develop software in the ways that work best for their particular situation while providing enough direction to help a team continually move toward their full potential.