Pair Programming and Code Reviews Can Work, Sometimes.

Inspired in response to Chris Fox’s piece “The Generational Divide in Software Developers”.

Image credit to sotheavy.

I wrote my first software for pay in 1986, as a summer intern in a factory where I couldn’t stand the awful logic in the automated test system: device fails? Sound the 94dB alarm in a room full of workers and keep it on for the next 5 minutes for no reason. Yeah, I can fix that for you. At University, having never heard the term “Pair Programming,” I did a number of paired projects with my lab partner and we were quite successful at completing more quickly and with higher quality as a pair than either of us could have separately. But, those were academic exercises with well known solutions and recommended approaches.

I graduated with a MS in computer engineering and started my first “real” job in 1991, coding graphics software for a medical company. Development methodology was basically unheard of in that time and place. We used the usual commercial compiler tools for IBM compatible PCs, I wanted to start the big project in C++, but the compilers available at the time were too buggy so the first iteration from 1991 to 1996 was done in C. Around 1994 the FDA rolled out “Design Controls” to which our response was to hire a dedicated tester who would mostly independently read my code looking for mistakes and document testing of the functionality. We worked for a recently retired doctor and were translating his ideas into product to sell into a very small market of similar physicians and researchers around the world. He was the real tester of product functionality, the software either did what he wanted, or it didn’t and I would try again until it did. I worked for him for 12 years, and in a sense we were a loosely paired development team with eyes on the same screen together for 15-30 minutes, three or four times a week. The doctor didn’t help with code, but we definitely worked out algorithms together.

This type of single developer software was fairly common in the early 1990s. A competitor / partner company of ours had a single developer named Ted. Ted wrote the first generation of computer control applications for their equipment, by himself, moving it from the dials and needles generation of technology to the first digital controls and displays. The “Tedware” was infamous throughout the sales staff, particularly after Ted resigned. None of them loved it, but they had to admit: it was all they had and it did work.

In 2006, I moved to a small medical device startup as the Director of Software development. They already had 3 software engineers and I hired two more with the mission of developing proof of concept software appropriate to impress potential investors, apparently it worked: they were bought out and moved across country within 9 months. While there I advocated, gently, for pair programming. We setup the office space with large desks and the 30” monitors we were planning for use in the product, and while we did 90%+ of our coding independently when there was an appropriate opportunity to pair on a problem we had the physical layout to facilitate that. The older gentleman I hired knew how to answer an interview question (whatever the interviewer wants to hear) and expressed enthusiasm for pair programming, but was highly resistant to it in practice. The younger hire, still in college, openly expressed distaste for paired work, yet over the following 6 months we had 4 or 5 productive pair sessions between 1 and 3 hours long in which we solved problems that had been vexing one of us for days prior to pairing. After the third successful session he expressed enthusiasm for pairing, when appropriate. Similarly one of the existing programmers had been struggling to integrate a cubic spline interpolation algorithm onto their existing code off and on for months, we sat down together after lunch one day and had it working well in less than 3 hours. In my experience, pairing is a powerful practice with very limited opportunities for appropriate application. You (used to) need the workspace layout to support it, or two people who don’t mind invading each others’ physical space for a while. And, it seems to work best on well defined problems, almost academic exercises, where both programmers know enough to spot each others’ oversights and are able to maintain focus long enough to hit a satisfying milestone.

At that same place, our pair resistant colleague was having trouble optimizing performance on his piece of the puzzle. He had parallelized it to run on four cores and achieved 3.5x speedup as expected, but it was still the slowest part of the entire process by far. So, we tried a code review one morning around 10am. An optimizer tool identified the problem area where all the time was being spent, four of us put the code up on a projector in the conference room and we traced through it - it was only a couple of pages long, we were done well before lunch. Once there, we identified an opportunity to restructure the algorithm and remove one of the nested loops - testing showed the output was still correct, identical to the previous algorithm, but execution time dropped by 99% - as will happen when you remove a nested loop that iterates the same problem 128 times. This was a big success for the software development team, suddenly instead of needing a supercomputer farm to meet our targets, we could run in near real-time on an ordinary laptop and better than real time on a single quad core desktop machine. However, despite everyone involved being as supportive and egoless as possible, it was a terrible blow to our pair resistant colleague’s pride. Within a few weeks he resigned.

These days I’m in a fortune 500 company at a location with 15 software engineers, and a sister site across the country with 50 more, hundreds more throughout the company but we rarely interact with those. We have procedures which require a certain number of documented code reviews and they are, sadly, mostly pro-forma worthless wastes of time and energy. We complain about them, but nobody is resigning afterwards. Our cube layout discourages pair work, when we did it the “cube invader” usually stood outside the opening or possibly pulled up a rolling filing cabinet as an uncomfortable seat too far away to really see the screen. Consulting with colleagues this way still helped get problems solved, but it’s not the same as working together on the same screen. Since the pandemic, I would think that screen-share teleconferencing would solve the physical issues with pairing, but with five+ years of established practice working independently we mostly still just solve our own problems.

For those of you not set in your independent ways, don’t be afraid to “get in the same headspace” with one of your colleagues for a few focused hours now and then, particularly when working on interfaces between your modules or problems that span between them. You don’t have to call it Pair Programming unless you want to, and thanks to the recent mass training on screen-sharing teleconferencing software, you don’t need to smell them either. Who knows, if you get used to reading each others’ code during pair sessions, you might even start doing some useful code reviews.