A technique that if done correctly has the potential for delivering software faster with lower cost
Humans are social creatures. The ability to communicate with other humans in order to efficiently learn and survive is in our biology.
According to Pascal Vrticka, a Social neuroscientist from Germany:
Becoming social has made us who we are today. Evolution has provided us with the best tools possible for successfully engaging in social interactions.
We naturally have the best biological tools to retain information efficiently through body language and face-to-face communication, but even with all this advantage, there is a big part of programming practitioners who believe direct and focused human communication in one specific task is not necessary to get the best of the job done efficiently. It is hard to know the major motivation behind that, but I can try to guess.
Many years ago when I started software development I also believed direct human communication wasn't necessary to complete a task efficiently. In my case, I was naively inspired by all those movies portraying a stereotype of hackers and engineers that could make anything possible by themselves alone. This mindset, enforced by the media, was responsible for a major step back in my career. If I could go back in time, I would tell myself otherwise.
The reality is there are so much Software Entropy, patterns and practices out there that it will be impossible for someone to achieve their full potential and produce good software by working alone. One of the secrets to growing and achieve one's full potential is to leverage other people's unique expertise and learn with them. Using direct human communication and collaboration to complete certain kind of tasks is one of the most efficient ways to grow. That doesn't mean the task will be perfect, but it means the knowledge acquired will be retained to complete a task with more quality and lower cost in the future.
That's one of the purposes of Pair Programming.
If we do this correctly, we will make a long lasting investment that will benefit everyone, from the developers that will learn efficiently, to the project owners that will experience software being developed in a less amount of time with more quality. Unfortunately, one of the drawbacks of Pair Programming is that it will take a considerable amount of time in the beginning until the team reaches a plateau. It all depends on the team and the Growth Mindset of its members for this to succeed. That's why an experienced coach is recommended to foster this kind of practice so that the risk of doing it wrong is reduced.
According to the paper The Costs and Benefits of Pair Programming (2000), Pair Programming introduces an initial development time cost of 15% but reduces fifteen times (1500%) the same cost due to the bugs that will be prevented because of it in the future:
In some organizations, developers’ code is passed to a test or quality assurance department, which finds and fixes many of the remaining defects. Typically, in systems test it takes between four  and 16  hours per defect. Using a fairly conservative factor of 10 hours/defect, if testing finds these “extra” 225 defects they will spend 2,250 hours — fifteen times more than the collaborators “extra” 150 hours!
If the program is sent directly to a customer instead of a test department, pair programming is even more favorable. Industry data reports that between 33 and 88 hours are spent on each defect found in the field . Using a fairly conservative factor of 40 hours/defect, if the customer is plagued by these “extra” 225 defects, field support will spend 9,000 hours — sixty times more than the collaborators “extra” time!
Pair Programming reduces fifteen times (1500%) the development-time cost it introduces
The problem with any technique that relies on a mindset is that it can be done wrong and have the opposite effect or be applied in the incorrect context. Being biologically prone to social interaction may not be enough. Every person is different. An effective interpersonal communication is not something that comes naturally, it requires a certain level of Soft Skill that needs to be trained and improved.
The Pair Programming origin is uncertain. According to the Agile Alliance, it dates back to the "Dynamic Duo" concept observed by Larry Constantine in the 70's, but evidence suggests it might have been practiced way before in the mid-50’s by Fred Brooks.
Today, Pair Programming is considered a pattern where both developers share the same computer, being one the Driver and the other the Navigator that helps the Driver with directions. However, there are some people that prefer to innovate and do things differently. For example, there are cases where a pair might prefer splitting the computer input so that one controls the mouse and the other the keyboard, helping to expose sync problems early and forcing them to adjust. Nothing is set in stone, the important thing is that the benefits are explored.
However, focusing on the mechanics of a pattern is like writing software focusing only on the syntax instead of the fundamentals. We need to understand the fundamentals and the purpose of why the pattern exists so that we can efficiently find the context that needs it and make experiments to see if it works in the case we want to apply it.
It is also important to recognize under certain circumstances people can be more creative alone and some teams may not yet have a mature mindset necessary for Pair Programming.
Pair Programming is a Forcing Function:
A forcing function is any task, activity or event that forces you to take action and produce a result.
It is a skill that yields the best benefit in a team if the aim is to build a high-quality software with low cost in the long run, but it is not a solution for all problems. It needs to be done right in the correct context and there’s a learning curve, as everything else.
This text originally appeared on http://medium.com/@fagnerbrack.