Sherlock Holmes had Watson. Batman had Robin. Laurel had Hardy.

In the real world, Marie Curie had Pierre Curie. John Lennon had Paul McCartney. Bill Gates, Paul Allen. And Steve Jobs, Steve Wozniack. 

When it comes to solving mysteries, fighting crime, making people laugh, discovering radioactive elements, making legendary music, and founding gigantic corporations that have changed the course of humanity’s relationship with technology, two heads seem to be so much better than one. 

Why shouldn't it be the same for software programming?

With this in mind, OSlash teamed up with Menlo Innovations to give our developers a deep dive into pair programming & test-driven development.

What is Pair Programming?

Pair programming is a development technique where two programmers jointly write code, usually at a single workstation.

‍The ‘driver’ keys in the code while the ‘navigator’ observes the written code for tactical mistakes and offers strategic inputs to steer the code in the right direction. In practice, the two switch roles often, and even the pairs themselves are switched from time to time.

Wouldn't it slow the whole project down, especially where deadlines are already tight?

After all, Brook’s law says it in so many words—Adding manpower to a late software project makes it later. In his book, The Mythical Man Month, regarded by many as the holy grail of software engineering, Fred Brooks states that it is irrational to measure useful work in man-months. Man-month is a hypothetical unit denoting the amount of work done by one person in one month. The conclusion he derives is that you can’t go faster on a project by adding members to your team. It is similar to expecting nine women to have a baby in one month, which is an impossibility, a logical fallacy.

But, what if we (and experts from Menlo, of course) told you that, with pairing, it is possible to defy this law?

Pairing can help you speed the project up and meet deadlines faster than anticipated.

‍We can take a fairly good guess at what you are thinking next.

How's that possible with two people working on the same thing and doubling the person-hours required to complete the project?

The short and quick answer: By improving the quality of work so that the testing ultimately reports fewer bugs and incidents and thus results in time saved on quality checks and corrections. 

The long(er) answer is below. 

Apart from the Yellowstone National Park Winterkeeper and the Warden of the Calf of Man, software developers have one of the loneliest jobs in the world. With nothing for company for hours on end except the screen, the keyboard, and the mouse, they slog on...writing line after line in isolation, in order to build something out of nothing. 

It is inevitable to get bored and lose passion for work that, under other circumstances, could be as joyful as it is useful and meaningful. 

By pairing two programmers together, pair programming introduces joy and excitement back into work.

Sophisticated creative tasks become pleasurable with ideas, inputs, comments, and feedback bouncing off the partnered developers in a state of constant flow. 

‍

With the key idea being “making your partner look good”, it builds a sense of deep trust and communication, so much so that it can make the whole difference between a company thriving or going down. 

‍

If it were not for pair programming, Google would not have been the search behemoth that it is today.

And the act of browsing the web for information wouldn't ubiquitously be referred to as Googling. ‍

‍In October of 1999, Google’s core systems had stopped working. No one among their top engineers could figure out the bug that had caused the failure of the system to crawl the web and build its index - the one function essential not just to the company’s identity but also survival. As a result, the search results retrieved by users typing in search queries on Google were dated, five months old to be exact. What made the glitch even more bothersome was that it could tip Google’s make-or-break deal with Yahoo. One that required them to power a search engine for the latter with an index ten times bigger than their own. And one upon which their financial survival was contingent. 

Enter the brilliant duo, Sanjay Ghemawat and Jeff Dean, Google’s first and only Senior Fellows and world class experts at what they do. It was they who figured out the root cause of the breakdown - not a software bug but a hardware problem. Working side by side, often on a shared workstation, they wrote code to prevent such hardware failures, even as Google grew and the hardware in use expanded at dizzying speeds. 

“Over four days in 2001, they proved that Google’s index could be stored using fast random-access memory instead of relatively slow hard drives; the discovery reshaped the company’s economics.”

Having worked together previously at Digital Equipment Corporation (D.E.C.), they liked writing code jointly and worked really really well together - an observation shared by most of their team members - so much so that their managers often built teams around them to optimize for productivity. Needless to say, Jeff and Sanjay are themselves proponents of pair programming, too.

You might counter us by saying that pair programming could only work out advantageously when two experts are cracking a problem together.

And that pairing an expert with a novice or worse, a novice with another one may be counterproductive.

Well, of course, everyone involved has to consider both the costs and benefits of the technique for their teams and projects, and adapt it accordingly.

An expert-novice pairing may feel slower as the former teaches the latter and two people go over exponentially more ideas, cases, and scenarios than a single expert working alone. But what it lacks in speed, it can make up for in improved quality and reduced mistakes, all while allowing the developers in a company a chance to question established practices, learn from the strengths of their partner, and compensate for their weaknesses.

Likewise, a novice-novice pairing can present a unique opportunity to the beginners to learn, practice their skills, develop new insights, and refine the manner in which they approach future problems.

Ultimately, pair programming seeks to bust the myth that an individual programmer can always be the hero or firefighter on a team.

Because, working with a team means practising code stewardship not code ownership. This is what sets everyone up for success, together.

And these are our key takeaways from the OSlash x Menlo Workshop on Pair Programming.

We are thankful to Menlo and can’t wait for #TheMenloEffect to kick in at OSlash. 

‍