Pair Programming: Pitfalls of Platitude

Is Pair Programming Bad?

On Quora, a question appeared about pair programming, which vilified the practise. Somewhat surprised, I chipped in.

So, this year, I celebrate 30 years as a programmer, even though most of my work is in enterprise architecture nowadays. Apparently, one of those rare breed of EA that is still very hands on.

I started programming in 1989, have built both electronic circuitry and brand new algorithms, across pretty much everything from embedded systems to 3D engines, to enterprise system and web scale cloud systems, work in high performance computing scenarios even now and work in both heavyweight waterfall and agile methods, the latter for 14 years and counting. I’ve done pair programming and lots of it in that time. Here is what I found across 20 different organisations in my time. Note, it’s not all positive, but I’ll present the positive ones first.

Knowledge Transfer

If you are new to the team or company, pair programming gives you the ability to quickly get up to speed with the technical aspects of the domain and crucially, the codebase. Make no mistake, the lack of good, useful technical documentation is the bane of lots of software projects, and developers evolved to hate writing them. Indeed, agile development’s first vocal proponents were those who used the agile manifesto to beat managers back with. So they are poorly written, bloated, obsolete and often meaningless. However, with folk who understand code, reading well written code is akin to reading documentation and with tests, you have the most important parts of old waterfall style documents anyway.

Architectural Guidance & Direction

Probably the most missed reason for pairing. Architecture, both noun and verb, live between stuff. Having an architect role (the choice of words is important), you have responsibility for conveying a design to developers and also a responsibility to the business to make sure the platform is built to deliver according to the manifestation of the value chain, at the lowest technical risk and in accordance with any road-map you produce or they want, to reach some target state (we call these intermediate roadmap states ‘transitional architectures’ and in reality businesses never leave transitions if they’re constantly evolving). In essence, decide the means, the speed and the direction of activity. This involves two crucial aspects.

Being Guided by the State of the Code

The biggest mistake I’ve ever seen in architecture or any programme is to think the company wants to get “there” but doesn’t know where they are now! Why is this important? Well think of it like a map. You want to get to the spot in the below map:

Your job as an architect (or even developer) is to answer the question “How do we get there?”. What is the first thing you notice? That’s right, there is no indication of where you are.

This doesn’t just affect architects or planner types. It affects new developers, testers and even the business (they have no idea about code). Pairing gives the developers and architects the ability to understand the starting point of the codebase.

Guiding the development of the code

This isn’t micromanagement. This is, say, writing the tests (if doing TDD) in such a way as to steer the code to a particular solution. For example, using the self-shunt pattern instead of a regular unit test with a mock. This drives a more asynchronous design with devs that know it than a regular unit test. Once you know where you are on the map and the state of the person asking you for directions, the time of day etc, then you can then guide them by making a suggestion as to which mode of transport to take. After all, the best mode of transport will be different between the blue and green triangles.

Once you’ve understood where the codebase and the developers are, you can decide which mode of transport is best to get there. Note, the devs can develop the code any way they wish as long as it’s readable, which brings me on to…

Quality Control & Immediate Code Reviews

Software developed in an iterative, incremental fashion often goes through code reviews to make sure that the code is not a bit rubbish, but also it’s an opportunity for folk who know other aspects of the codebase to help someone identify duplicate functions, methods, classes, components and the like (note, waterfall has cycles in it too, which return the previous stage’s deliverable if something changes in the current one — going one way is often a misnomer and I’ve seen this most in the agile community). It also allows the pair to introduce and validate coding standards in the same step. Otherwise, this would go to some weekly or bi-weekly code review process which in turn, means the code is not ready until at least that code review is done. That could be up to two weeks after it is written. Ongoing QC shortens that cycle.

Inter-component Interfacing

This is hugely important. Components talk to each other through interfaces of some sort. You can read the documents if you want, or you can pair with the person who wrote it. Not just that, but you can use “consumer driven contracts” by writing the tests for what you, as the consumer of the interface, need to see and they can write the code to make it pass. They as the publisher, know their code better than you and although they could write code to validate your requests, in many circumstances, it’s quicker if you tell them what you want. If the code need to be consistent for all other consuming clients, then things like normaliser patterns or integration platforms become useful, as they transform socket, web service or REST requests into the producer/publisher’s format and back again. Again, shortening the cycle.

There is lots more, but let’s move on to the negatives.

It’s Exhausting!

As introverts, including me believe it or not, the whole process can make you feel drained. Having to constantly switch from screen to what the partner is saying and multiple phases within the process (as listed above) is very fast context switching, and each has a mental cost, no doubt about it! So the personalities have to be compatible and work in a particular way. I found it’s easier for one person write the test, the other to make it pass (pass the keyboard between the two of you) and that same person to write the next test. That is:

1. Dev 1 writes the test (red failing test), passes the keyboard to Dev 2
2. Dev 2 makes it pass (refactor — I don’t do it here…)
3. Dev 2 commits the code
4. Dev 2 writes the next test and passes the keyboard to Dev 1
5. Dev 1 (refactors the code to place the next functionality — this is where I do it. Note, run all but that one new test as regression)
6. Dev 1 writes the code to make the new test pass
7. Dev 1 commits the code

That reduces the context switching and the other person then refactors the code of the first person, instead of ‘talk-typing’ .

It Slows you Down & Makes Pure Coding Less Effective

I found this the hardest thing by far and you don’t appreciate why until you stop to think about how much you are doing. Given you are doing all of the above, including some aspects of testing, understanding code that isn’t your, understanding the functional domain etc. this is a lot of activity! A lot. So no wonder you’re getting slower and it feels like it’s less efficient and it is…

…but only for you!

Remember, software development has an SDLC. It starts way before code is written and ends when the software is retired, not when it’s launched. That is when value is delivered and is the optimal line. Optimising just for programming is almost always suboptimal (even though it is often the operational constraint in the system). I definitely agree with all the research that has found that open spaces and pairing is bad for individual productivity. I personally spend a lot of time alone when thinking about complex problems and me personality is very very different when I’m in flow. But that’s not what software development is always about. It’s delivering value.

The key with software is to get it through the majority of the SDLC with high quality code that is quickly developed. This will often come at higher cost, but actually doesn’t have to (this is one of the biggest fallacies of software’s Iron Triangle, because it does not consider failure demand and shorter cycle times). If you do more of the automated testing for example, less has to be done by the QA’s and testers, especially through a formal manual testing process which, because there is a human involved, is both slow and error prone. We’ve all probably seen the testing triangle:

If tests are well written and have good coverage, then it has less bugs slip through the net and what does get through gets detected no more than 10 minutes after it’s written, but ideally, seconds. Pairing with someone, including a Developer in Test (a QA who is a coder) allows them to navigate for you. To determine where you might want to add coverage if it isn’t there. They’re watching out for the little mistakes. In essence though, they are trying to compress the pipeline as much as possible which compresses the timeline as much as possible.

It’s costly… but it’s not. You make it up in value.

Only a half truth this one. Most people who use this don’t manage budgets (or manage them properly) and really don’t have any idea about the financial effects development has on a business. There are two aspects to the value of something.

1. How much it costs to make — Some developers cost twice as much as others…
2. How fast you can get it into the customer’s hands for them to get the return on their investment in 1. Those same developers are 20 times as productive as others.

Yet those developers only cost double. What does this mean? That means for every $100 spent on developers in an hour, they will have a rate of return of up to $2,000, compared to a return of $100 dollars on a $50 hourly investment. To pick on a misguided financial practise, Cost Accounting is absolutely the killer of businesses, because they always seem to cut out the highest cost, without considering the value they deliver. This happened recently at a very large (the largest) corporate IT organisation. It’s amazing a company like that still thinks like idiots and are pretty much the worst level of idiotic thinking I’ve seen in the industry.

If you have two A-list, world class devs, they deliver value at 20 times the average rate, precisely because they are considering the work of them and the rest of the team. So they replace 40 other dev days for every 1 day they each do. 40 other devs all need managing and their interactions get combinatorially more complex. 2 folk have 2 communication channel directions (one to the other, the other to the first), 3 folk have 6, 4 folk have 12 etc. that’s why managing 40 devs the old fashioned way is a ridiculous thing to do. That’s the biggest fallacy that becomes project managers. That people can just be replaced like Lego blocks. The block isn’t the value. So pair programming, for what it returns, is better than not having it </rant>

Find two Compatible Developers

This is a chronic problem! The worst thing you can do is find two incompatible personalities. You get a lot of this, which is symptomatic of bad pairing culture:

• “Jumped up little upstart. I have been programming since before you were born…”
• “They just sits there, doing nothing! Having them sat beside me is a total waste of time!”
• “They’re always reaching over and taking the keyboard whilst I’m thinking. It’s off-putting”
• Thinking “They invade my personal space” (this happens tonnes, is under reported and you can see it in body language. So be mindful of it!)
• “We’ve got QA’s for that” <- Suboptimal, wasteful thinking.
• Not talking nor sharing knowledge through the pairing exercise <- Job insecurity(?)
• Not stopping to think before typing on the keyboard — People often accuse others of analysis paralysis. However, they may be considering other directions you have not so far. So be mindful of that too…

Senior with very junior doesn’t work brilliantly. Both the enthusiasm, experience and skills are different. This works both ways though. So juniors have to be mindful of that too. Seniors have to nurture an environment which fosters collaboration and communication to allow juniors to contribute.

Also, companies have to allow private spaces. They risk alienating some of the best and brightest if they don’t. So don’t force pairing all the time. If someone needs to have time to think, provide a space for them to do so. It can be anywhere. Their desk, an office, the canteen, a formal “breakout area” etc.

Summary

Pairing is much much harder than people think. It brings with it a lot of benefits, has some not insignificant drawbacks, but needs complementary culture and personality. That is what teamwork actually is! Top to bottom. Get it wrong though and it can destroy your team. So it’s got to play out right.

Best of luck!

The original article appeared on Quora. You can read it here.