Hidden benefits of pair programming

Humberto Bernabé
5 min readMay 24, 2020
Benefits of pair programming

Pair-programming is a way of programming that often is associated with helping fresher programmers to learn and increase their knowledge.

There are undoubtedly big benefits of pair programming when an expert programmer teaches a novice, but is that all that there is to it?

What other benefits does pair programming have that we as an industry are overlooking, other than just transferring knowledge?

Facts

What does science tell us about pair-programming

[..]. However, the resulting code has about 15% fewer defects. Along with code development time, other factors like field support costs and quality assurance also figure into the return on investment. Pair programming might theoretically offset these expenses by reducing defects in the programs. -Wikipedia

There we have it: 15% less bugs. When we carefully consider this very important fact, we find out that 15% percent mean very much in actual profit and benefit.

Let’s take a look at the numbers surrounding bugs:

The cost of a bug is between 50 $ in the requirement, 1500$ in QA, and 10000$ in production. -https://crossbrowsertesting.com/blog/development/software-bug-cost/

The industry average is estimated between 15 and 50 bugs per 1,000 lines of code

A bug gets counted as a bug if it is in finished code (published, or in production, or otherwise supposed to be bug-free)

Bugs have severity ratings. A severity 1 bug stops all use of the program. A severity 2 bug stops some users but not all. A severity 3 bug is inconvenient, has a workaround, or is an annoyance.

The most professional development organization I ever worked in, which created software products for worldwide use, and had an enviable reputation for excellence, worked to an expectation of one severity 1 bug per 1000 lines of shipped code. -https://www.quora.com/What-is-the-average-ratio-of-bugs-to-a-line-of-code

What should be clear to us now is that the cost of bugs is very high and 15% fewer bugs can easily outweigh the increase of manhours by pair programming in the end. We might even gain an advantage by doing so.

Plus there are other benefits that are added by pair-programming, that will further increase the code quality and productive output.

Increased Design Quality

Again Wikipedia does a good job of sourcing the information:

A system with two programmers possesses a greater potential for the generation of more diverse solutions to problems for three reasons:

  • The programmers bring different prior experiences to the task;
  • They may assess information relevant to the task in different ways;
  • They stand in different relationships to the problem by virtue of their functional roles.

In an attempt to share goals and plans, the programmers must overtly negotiate a shared course of action when a conflict arises between them. In doing so, they consider a larger number of ways of solving the problem than a single programmer alone might do. This significantly improves the design quality of the program as it reduces the chances of selecting a poor method.

Clearly being able to solve an issue coming from different angles is better than having only one alley to attack from. Flanking our problem, will lead to to higher quality in our code base.

And increased software design quality can mean higher reliability,efficiency, security, and maintainability amongst others.

To pick out the example of maintainability: Better maintainability will mean we end up again with fewer bugs. This means again more profitable software . Its a win for the customer, the developer and the company.

Developer statisfaction

From Wikipedia.com:

In an online survey of pair programmers from 2000, 96% of programmers stated that they enjoyed their work more […] and 95% said that they were more confident in their solutions when they pair programmed.

If we look into the science of workplace satisfaction we can clearly see a correlation between retainment rates and productivity. The following study states:

Gallup researchers found a direct relationship between dissatisfied workers, absenteeism and productivity. Companies with large numbers of dissatisfied workers experienced more absenteeism and lower work productivity.-[1]

Not mucht to add here.There seems to be a clear indication that it would be a win-win situation for both the employer and the employees if workplace satisfaction rises. After all we try to work together and not against each other.

4) Learning

As stated in the beginning pair programming is a great tool to share knowledge between programmers.

Knowledge is constantly shared between pair programmers, whether in the industry or in a classroom. Many sources suggest that students show higher confidence when programming in pairs, and many learn whether it be from tips on programming language rules to overall design skill. -wikipedia.com

It should be clear that more knowledge, especially in this field, leads to better results and is something every programmer strives for or should strive for.

Communication

Pair programming allows team members to share problems and solutions quickly making them less likely to have hidden agendas from each other.

This helps pair programmers to learn to communicate more easily. “This raises the communication bandwidth and frequency within the project, increasing overall information flow within the team.- Wikipedia.com

Again the effects of better communication are big benefits to any company and to the individual skills of any programmer.

To quote study.com:

Research has shown that effective lateral and workgroup communication leads to an improvement in overall company performance. It has also been discovered that employees who were graded as highest in production had received the most effective communication from their superiors

There are many sources that indicate that workplace communcation is a driver to success. Read here for more:

Pitfalls

Of course, there are pitfalls and pair-programming is not advised in every situation:

Again wikipedia for the rescue:

On simple tasks, which the pair already fully understands, pairing results in a net drop in productivity.

It may reduce the code development time but also risks reducing the quality of the program.

Productivity can also drop when novice–novice pairing is used without sufficient availability of a mentor to coach them.

These are important points to consider and in any way pair programming should always be done the right way.

  • Respectfully, polite, and supportive.
  • Talk a lot and clearly define your goals.
  • Let the more junior programmer take the steering wheel as well.
  • Switch roles often.

For more information on how to do pair programming right i recommend this source:

https://www.wikihow.com/Pair-Program

Solutions

Not only do we achieve better, more effective solutions with pair-programming. We would also be able to improve our design quality and workplace satisfaction and intra-personal communciation.

Pair-programming is an important tool in our tool-box and should be used more often. It takes our social nature better into account and increases the expertise behind our solutions. And that’s what we deliver in the end, solutions that matter to us, the customer, and the company.

Sources:

[1] (https://deepblue.lib.umich.edu/bitstream/handle/2027.42/143415/Carnahan.pdf?sequence=1&isAllowed=y)

--

--

Humberto Bernabé

Software developer that uses a pen || productivity || tech || self-improvement || health || free shrugs ¯\_(ツ)_/¯ ||