This post is one part of a series of posts about Pair Programming.
- Part 1: Pair Programming.
- Part 2: How to find the best context for Pair Programming.
- Part 3: The Power Of Pair Programming Lies On The Execution.
- Part 4: How to do Pair Programming The Wrong Way.
Humans are social creatures. The ability to communicate with other humans 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.
You 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 interaction in one specific task is not necessary to get the best of the job done efficiently. It is hard to know the 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. There were all these movies which portrayed a stereotype of hackers that could do anything by themselves alone. They naively inspired me. This mindset, enforced by the media, was responsible for a significant step back in my career. If I could go back in time, I would tell myself otherwise.
If I could go back in time, I would tell myself that one of the fastest ways to learn is pairing with somebody else frequently, from the beginning to the end of a job.
The reality is there are so much Software Entropy, patterns, and practices out there that makes it impossible for someone to achieve their full potential and produce good software by working alone. One of the secrets to growing and reach 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 work will be perfect, but it means the knowledge acquired will be retained to complete the job with more quality and lower cost in the future.
That's one of the purposes of Pair Programming.
One of the purposes of Pair Programming is to leverage other people's expertise to learn more efficiently and complete a task with more quality and lower cost
If you do this correctly, you'll make a long-lasting investment to benefit everyone. The developers to learn efficiently, and the project owners to experience software developed in a less amount of time with more quality. Unfortunately, one of the drawbacks of Pair Programming is that it requires a considerable amount of upfront investment until it starts to pay back. It all depends on the team and the Growth Mindset of its members for it to succeed. You can reduce the risk if you have access to an experienced developer that can help to foster this kind of practice.
According to the paper The Costs and Benefits of Pair Programming written in 2000, Pair Programming introduces an initial development time cost of 15% but avoids 15x 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 2250 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 9000 hours — sixty times more than the collaborators “extra” time!
Pair Programming avoids 15x (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. You may have to train your Soft Skills to be effective in interpersonal communication. It's not something that comes naturally.
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 some people suggest 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. One is the Driver, and the other is the Navigator who helps the Driver with directions.
However, some people prefer to innovate and to 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, which helps to expose synchronicity problems early and force them to adjust. There's no definitive guide set in stone. The important thing is to explore the benefits.
Pair Programming is a pattern where both developers share the same computer. One is the Driver, and the other is the Navigator that helps the Driver with directions
However, focusing on the mechanics of a pattern is like writing software focusing only on the syntax instead of the fundamentals. You need to understand the fundamentals and the purpose of why the pattern exists so that you can find the context that needs it and do experiments to see what works and what doesn't.
It is also essential to recognize under certain circumstances people can be more creative alone. Also, 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. However, it is not a solution for all problems or a short-term result. It needs to be done right in the correct context, and there’s a learning curve, as everything else.
If you want to know more, see also how to find the best context for Pair Programming.