Wow! It is hard to believe that I'm at the end of my first stop and on the train to number two. Pairing these last three days with David Chelimsky has been a true treat, and I am more confident than ever that this tour is a great idea. I've written some really cool code, submitted a patch to an open source project (Radius), and met some very interesting people.
On Monday night, I had the pleasure of speaking at the Chicago Ruby Brigade (see video of the presentation), followed by beers at a local pub with some of the members. We had some great conversations about agile practices. One thing that really stuck out for me was Dean Wampler's comment that one of the original intentions for the practices was to allow 'average developers' (watch out, loaded term) to be more successful. This is something that really has caused me to think about my view of 'Agile' in the world. This isn't to say that the practices are not applicable across all skill/experience levels (they are, and I believe they will make anyone more successful), but the practices, themselves, are not only for the 'elite.' The term 'Agile' has a lot of strong associations in my mind, being more of a philosophy than a set of practices. It also reminded me of the idea that, if you are going to implement the XP practices in your organization, you need to implement them all. For example, incremental design and YAGNI have fantastic benefits, but if you don't pair them with other practices, such as TDD and CI, you potentially are going to run into some serious problems later when you go to add those "waiting until I need it" features to an existing codebase.
I've known David Chelimsky for a little more than 4 years now, having met him at the 2004 Agile XP Universe conference. I've mostly run into him at the agile conferences, although we've kept in touch here and there online. Since I've been doing more Ruby, our communication has been more frequent, due to his involvement in RSpec and my love of using it. Over the past four years, we've paired a handful of times on different things, so I didn't have any fear that we would run into any hiccups. From my perspective, I couldn't have been more right: pairing with David was awesome. David's experience with pairing really showed through in the constant communication both verbal and non-verbal, resulting in very smooth transitions that blurred any thought of "controlling the keyboard." One of the great things that I've found when working with an experienced pair-programmer is the lack of having my attention drift away when the other person is typing: I was engaged almost constantly. This creates a very easy transition between different styles of pairing, including ping-pong, driver-navigator and tester-implementer.
From a very selfish perspective, I learned some cool tricks and techniques in Ruby and RSpec. RSpec is definitely my preferred framework for specs, and it was exciting and very instructional to work with the primary maintainer. For example, I am now much more comfortable with things like the following:
lambda { do_something }.should change(MyThing.count).by(1)
in a spec. Or, checking for errors:
lambda { do_something }.should raise_error(ActiveRecord::RecordNotFound)
The application we worked on was using Merb, rather than Rails, which was a new framework for me. It is similar, but there are definitely things that I was impressed with. I'm probably going to stick with Rails, as the freelance job that I'm starting is using it, but I want to look more at Merb, for sure.
Another thing I was exposed to was Radius, which looks to be a super cool tagging system. It supports the equivalent of tag_missing, which allows for some cool tricks. While using it, we found a small part that was a bit annoying (to me, at least), so we forked it on github, added a shortcut, then submitted a pull request to the author.
I will be taping an interview with David on Friday morning concerning his experiences, and I plan on having time to edit and post it this weekend.
Next stop, spending a day pairing with Uncle Bob Martin.