push.cx
Peter Bhat Harkins
Craftsmanship Tour: Obtiva
Last month when I started planning my travels of indefinite duration, I ran into the blog On Being a Journeyman Software Developer by Corey Haines. He spent the end of 2008 and most of 2009 traveling around the United States pair programming in exchange for room and board, trading knowledge and having interesting discussions. I saw it and thought, “Hey, I could do that.”
I chatted with Corey about his experience and he encouraged me (and every other developer, really) to visit and learn from as many software developers as I could. To this end, he and Scott Parker introduced me to folks at Obtiva and 8th Light, two local consultancies that are part of the software craftsmanship movement, with the encouragement that I visit places even before I leave Chicago.
Obtiva
{.alignright .size-full .wp-image-1522 .aside width=”241” height=”53”}
I’ve gotten my programming tour started. I spent yesterday at Obtiva pairing with Andy Maleh on some client work. We tracked down and fixed a bug, added a straightforward feature, and added a feature that exposed a hidden assumption in the spec and required some refactoring.
This was the first day I’ve spent pair programming and I really enjoyed the experience. There were some tools I hadn’t used, and Andy’s ability to answer a question, give an example, or push me to try it (“Here, you drive”) at the exact time I was wondering how to do something made for quick learning. We traded off responsibilities smoothly, with one of us writing the implementation and the other watching for typos and thinking of different possibilities. There were a few moments when I felt like I had a second brain because I had Andy’s knowledge to draw on or because he pointed out a problem I wouldn’t have noticed for a few minutes because I was heads-down on the current task.
Cucumber
{.alignright .size-full .wp-image-1524 .aside width=”73” height=”71”}
One of those new tools I saw was Cucumber, a test framework for behavior-driven development and acceptance testing. You write your tests in lightly structured English and then write code to implement each step.
I’d seen a lot of talk around Cucumber but ignored it because I’m happy to write my high-level tests in Ruby. I don’t have a non-technical customer to show them to, so I didn’t see a benefit. I’m very glad to have gotten a little experience using Cucumber. It forces you to write a DSL for testing your app, with small, well-named methods to encapsulate each step of the process. It’s a great exercise that I’d recommend for anyone who writes automated tests (which is all developers, right? *cough*).
Dehumanize
As we were tidying up some Cucumber tests, I noticed a bit of repeated code that transformed an English description like “Phone number” into a column name like “phone_number”. We were about to abstract it to a small method, when Andy mentioned he’d submitted a small patch to Rails a while ago that was not accepted. Perhaps inspired by the recent accomplishment of a former coworker, I said, “Why don’t we package a gem?”
So that’s just what we did, creating the dehumanize gem for this snippet to perform the inverse of ActiveSupport::Inflectors#humanize. Jeweler made it the work of a minute to package and publish; we spent more time retrieving Andy’s lost login to publish to RubyGems.
Aside from all these new toys, we had a nice running conversation on the size of commits and using feature branches. My tendency is to make much smaller and more frequent commits than Andy, and to break work off into branches much more often. Look for a blog post about it in the next few days.
Are you in Chicago?
If you’re in Chicago now and would like to spend a day pair programming with me, please contact me. There’s a lot to learn from each other, and it’s a lot of fun. At the least, you can follow this blog’s RSS feed or me on Twitter to see how it goes.