Pair Programming Trails

19th June 2015
Gus Power

Pair Programming As A Workshop

Yesterday I had the opportunity to pair programme for a few hours, something I don’t get to do that much of at the moment. I find it helpful to frame pair programming sessions as workshops of size two. This frame reminds me to be a bit more structured and get more out of the time we’ve got.  Like any workshop, an agreed agenda (what we’re going to do and how) and desired outcome (where we’d like to get to by the end of it) really help.

The aim of this session was to spike whether we could easily integrate with a 3rd party public API of a CDN provider we’re evaluating. Since we hadn’t worked together before we started with a brief whiteboard chat about what technology we were comfortable using – language, editor, build tool, test tool and so forth. Then down to business. I have the luxury of a standing desk at the Energized Work lab so we agreed it was ok to work there. We set it at a comfortable compromise of our mean height and began.

Leaving A Trail

I often use personal kanban or a handwritten task list while pairing to chart out the initial trail – what needs to happen and in what order – and update it as we go. Lately I’ve taken to using the bottom of my monitor for post-it notes containing my prioritized list of tasks (left to right) so I figured I’d try something similar for this session. I had a single post-it note on the left indicating our overall goal (‘List Zones’). As we moved from topic to topic I asked what we were now doing, wrote the topic on a post-it and stuck it beside the goal. We ended up with the following trail:

  • Setup project
  • Setup test
  • Aarrgghh logging
  • Setup service
  • Loading config Aarrgghh
  • OAuth 🙁
  • Deserialize zones
  • Get zone name

Looking Back

After about 90 mins we had reached our destination: ‘List Zones’. We used the trail we had created to reflect on what we’d learned. As we ran through each of the topics in turn we recalled the surprises and difficulties we had encountered along the way. There were quite a few:

  • Intellij’s support for maven is quite impressive, but the package versions it recommends are unfortunately not up-to-date.
  • The latest Spring stuff uses logback by default, so an easy way of setting logging levels requires a logback.xml on the classpath.
  • In our minimal setup, using @Value to load settings from a properties file just didn’t work. After some digging it seems that we were missing some configuration but we had a workaround using Environment.getProperty(). More investigation required.
  • Lombok @Data is cool. It eliminates the need for much of the typical Java boilerplate.
  • The 3rd party uses 2-legged OAuth 1.0a with an empty oauth token.
  • Spring has an OAuthRestTemplate which is a bit clunky but works ok. You can get the response body for failed requests from a specific method (getResponseBodyAsString) on the exception that is thrown (!).
  • We ended up with a set of nested objects that mirrored the 3rd party API response structure for Jackson serialization which was a bit cumbersome, but we could at least ignore fields we were not interested in.
  • Spring downloads *a lot* of libraries. Wow.

I was surprised just how much I’d learned. I’m not that familiar with the technology used so much of it was down to my own ignorance, but nonetheless the trail served as a simple and useful device.

Here it is in all of its high-fidelity glory:

pair-programming-trail-smallPair programming trail

The Pen Is Mightier

I’ve always found that simple physical devices – paper and pen, post-it notes, index cards, magnetic whiteboards – have a much lower barrier to entry than their technical equivalents. It’s easy and quick to try out new ideas. There’s something about them being ‘in the real world’ that makes them more fun to use, less serious and less onerous than online tracking and drawing tools.

No comments

Leave a Reply

Your email address will not be published. Required fields are marked *