Pair Programming: API exploration
A colleague and I were working on some code a couple of weeks ago which mostly revolved around investigating the C# reflection API to work out which methods we needed to use.
My colleague was driving while we were doing this and our progress seemed very much based on intuition about the API rather than being gradual.
In fact it was quite similar to one of the situations in which Uncle Bob suggests TDD doesn’t work so well:
... I need the freedom to fiddle around with the formatting and the structure until everything is just the way I want it. Trying to do that fiddling with TDD is futile. Once I have the page the way I like it, then I’ll write some tests that make sure the templates work as written.
My colleague was fiddling around with the code trying to work out what combination of methods we needed to call and I was struggling a bit to get involved through no fault of my colleague.
He was describing what he was doing but for a lot of the time what we tried didn’t work and then suddenly it worked.
It all seemed a bit magical to me!
At this stage we decided to refactor the code and thought that it would might be useful for me to do that refactoring so that I could explain my understanding of the code my colleague had just written and see if I had followed what he’d been doing.
I was able to extract out methods correctly most of the time but there were a couple of places where I hadn’t quite understood what was happening so this approach allowed my colleague to explain it to me.
My initial thinking when we started doing this coding was that perhaps it wasn’t suitable for pairing because it’s quite exploratory but it seemed to work out reasonably well and my understanding of reflection is now slightly better thanks to my colleague’s explanations.