Experience Report: Pairing with a Programmer

Background
It was one of those typical "do or die" scenarios: A feature was implemented that was critical for the project but it was delivered late due to slightly optimistic estimates. To make matters worse it touched on rather fundamental parts of the product making it somewhat complicated to roll back. The job was to quickly test, fix bugs and, in corporation with our product owner, decide if the feature was ready to be released. The feature in this case was rather technical with a simple interface that, depending on configuration, triggered tons of background activity including communication between different servers.

What we did
Me and the programmer teamed up. The first day we worked in front of his computer only. Initially he pretty much explained the feature and I noted down some thoughts and scenarios that popped up in my head. When done we started with the most straight forward scenarios and immediately found some serious bugs that required extensive investigation and experimentation to fully understand. We managed to solve the most critical ones and left not that late feeling really good about ourselves. Day two would be a breeze!

Day two we made an "upgrade" and booked a room as well as brought one computer each. Immediately we found out we had badly underestimated the work left as critical bug after critical bug emerged. As some of them required knowledge we lacked we called in a domain expert to help us and continued to work all three together for the rest of the day (one computer each). Day two turned into a 12 hour long exploration and bug bashing. When done we felt slightly exhausted but proud, it was working!

Some info about the group
I'm a decent programmer and a good tester. The programmer in this case is fairly young but good programmer progressively becoming a better tester. Finally the domain expert is a bit of everything. He knows the system and customers as well as having a fairly good understanding of both programming and testing.

Observations

• We had fun! Personally I liked day one best, not because the presure was somewhat lower but because we cooperated more when sharing one computer.
  
  
• Continuing on the track of computers: I think from an efficiency standpoint one computer each was, short term, mostly more efficient (possible exception would be during the most intense and mind challenging investigations). It's important to note that one computer each didn't mean we just sat together testing individually, what we did was to work together on one task but doing different things (like taking notes, executing tests, monitoring logs, correcting code etc.). Working together at one computer though was a more learning experience and, as I said before, I think it was more fun if that counts for anythings.
  
  
• I feel very comfortable saying we would not had caught and fixed anywhere near the amount of bugs we did if working separately. A few reasons why:
• We have different investigation methods. The programmer did low level investigations really well adding debug printouts, investigating code etc. while I did high level investigations really well checking general patterns, running additional scenarios etc. Not only did this make us avoid getting stuck by changing "method" but also, my high level investigations benefited from his low level additions and vice versa.
• We could share some of the work, for instance I took notes as the programmer ran scenarios. This helped us avoid losing momentum.
• No time was wasted performing handovers from bug reporter to bug fixer back to the reporter.
  
  
• When we worked all three together I felt we often worked in one pair and one person alone (not all the time but most of it). In this case it was probably the right thing to do as we required all three persons' skills but I think that was an exception. My general judgement, only based on my own experiences, is there is little or no gain in being three compared to two if you don't really require everyone's skillset more or less constantly.
  
  
• We learned so much!:
• All three learned new things about programming, the system in general and testing, both from each other and from ourselves explaining stuff
• I learned more about logging in general
• I learned more about the system and feature
• I learned more about the code/code architecture
• I learned more about the others' strengths and weaknesses
• The programmer got help being skeptic about his own code
• The programmer learned some new scenarios his implementations need to handle
  
  
• We got to know each other's personalities and skills better which fosters trust/respect/team spirit.
  
  
• It made us communicate more which helped us gain from everyone's observations (sometimes an observation was communicated that didn't mean anything to the one making it but did to someone else).
  
  
• Pairing also made us stay focused for longer stretches (you don't want to be the first one to procrastinate).
  
  
• A byproduct was code review. As we investigated code sections other improvements/problems/potential problems became apparent and fixed.
  
  
• One thought that popped up was working separately and then pair as problems occurred. However, that would require time to be spent rerunning the actions, explaining the steps and possibly missing crucial details from the initial run. All and all I think there's a place for that kind of approach as well but not that often.

Sum up

I did pair up with programmers quite a few times at Ericsson and found it useful but for some reason I haven't done it on my current job until now. I will definitely continue doing it though, for the learning experience, for the laughs and for the (at least perceived) efficiency gain. Luckily it seems I wasn't the only one feeling that way!