My Guest Appearance on a Hashrocket 3-2-1 Project

2:08 PM EDT Friday, August 15 2008

This week I took a brief hiatus from my normal job at BrowserMedia to spend a week on a 3-2-1 project with Hashrocket with fellow guest stars Hampton Catlin and Matthew Bass. It was a great experience for many reasons.

One of the key factors that made this 3-2-1 possible is that not only do we all use good tools, but we all use the same good tools. All of us use Macs, Textmate, Git, Rails, RSpec, Restful Authentication and Haml. This allowed us to hit the ground running. All the basic infrastructure needed for building a web app was in place, so were able to get going and focus on the core functionality of the app.

Pair programming, at least to the degree that it is done at Hashrocket, was a new experience for me. Every developer works in a pair programming setup, with a laptop hooked up to a 30-inch display and two keyboards and two mice. Having a large monitor, two keyboards and two mice may seem like a luxury, but it really helps you get into the flow of pair programming.

Another core philosophy at the heart of the Hashrocket methodology is test-driven development (TDD). TDD is something that most agile development shops strive to do, but sometimes fall short. I believe that two of the main reasons many teams struggle getting TDD right are tight deadlines and lack of developer expertise and discipline. All developers who try to do TDD have experienced this at some point. You've got a feature that needs to be cranked out ASAP, you're not exactly sure how test it, so you just dive into the code and pound it out. My experience at Hashrocket has taught me that that all too common scenario can be avoided by practicing pair programming and TDD together.

One pair programming technique that makes TDD easier is ping pong pair programming. When doing ping pong pair programming, when you sit down to build a feature, the first person in the pair writes the test. Next, the second person in the pair writes the code to make the test pass. Then the second person writes a test for the next feature, and the first person in the pair implements it. By repeating this process throughout day, you have several benefits. First of all, it avoids the scenario where one developer does most of the work and the other developer just zones out and gets distracted by something else, because you are constantly switching back and forth. Also, like two people who go on a diet together to help each other stick to it, one developer doesn't let the other developer get lazy and skimp out on the tests for a specific feature. That doesn't apply just to the test. As long as you have a pair of two experienced programmers, one of them it's going to let the other get away with writing a nasty piece of code. It's like a real-time code review.

My favorite aspect of the 3-2-1 experience was having the time to spend with other good software developers and just discuss the process of software development. TDD was a topic of conversation all week. Some believe in a strict adherence to TDD, "Test all the fucking time", if you will. Others believe TDD can be a warm blanket. It's easy to fall into a mentality that the tests pass, therefore the code works. Human testing can be a more effective process for discovering bugs in software, but human testing gets much less emphasis than TDD. I believe there is a lot of value in functional testing with tools like Selenium and I would like to see more emphasis on functional testing in the community. For my next project, I'm considering just specing the models and testing the rest of it with Selenium. If you are following the best practice of SCFM, you controllers should be mostly glue code anyway, so you get more out of testing from the browser via an automated, repeatable test than unit testing your controllers. It was a healthy debate and great to have a chance to be part of it.

I suggest all developers, whether you are an independent developer or a full-time employee for an organization, find an opportunity to participate in a 3-2-1. The amount of knowledge sharing that goes on is invaluable, exceeding what you get out of attending any conference. You spend the entire day pair programming with other top-notch developers and the evenings discussing all aspects of software development. This is the type of environment Evan Light envisions for DCamp. Developers working together, one-on-one, sharing knowledge and trading best practices.

Posted in  | Tags Rails, Ruby

Comments Feed

1. TATFT

This is a hard thing to do. I'll be the first person to admit it. Another thing that I admit, is that I do *test* all the time.

Spikin' is natural, and a good thing, but after you are done, get rid of all that spikey code and TDD the new feature in. This is hard thing for *all* of us to grasp, because it never makes sense at the time.

One thing of note that I would like to share is that sometimes you'll come to a point where you can't TDD. At that point, I'll offer some advice... you most likely don't understand the problem as well as you think you do. What you may need to do is try it again from a different angle or maybe you need to think larger and stop scoping so small.

Whatever you do, make sure you are testing, because if you aren't, all you are doing is making it harder for yourself when you revisit the code, and making it even harder for the next developer who will inevitably have to maintain what you just wrote.

Peace, Hair Grease and TATFT

# Posted By bryanl on Friday, August 15 2008 at 02:55 EDT

2. Awesome blog post, Paul. You've really captured the sense of code-community that Hashrocket provides.

P.S. PATFT!

# Posted By Veez on Friday, August 15 2008 at 03:14 EDT

3. I play a minor supportive role in the Hash Rocket (HR) Company. After reading your narrative I feel very proud to be involved at any level.
The practice of bringing in outside sources and talents to expedite client needs has shown me what progressive thinking can do for a company, an industry and those directly affected by this brilliant move.
It shows a confidence of talent that I have never seen in the corporate arena. It seems to me that their eagerness to infect the rest of the industry with this program pairing would make them easy prey to one-upmanship or becoming mediocre in an ever-growing industry. This is so far from the actual that if I did not know the brilliance of the talent employed by HR; I would think them arrogant.
Anyone meeting, working, conversing online or partying with these people know them to be so far from arrogant as to almost think them as altruistic, earth-muffins. Willing to give away the shirts off of their backs; just try to get a HR t-shirt and experience the tug of war that would make a Labrador with a tennis ball blush.
I joke with others that I have no idea what Obie and the others do when locked up in their dark caves from sun up to down. By putting your experience online; you have added one more piece of information that others have been unable to impart.
Thank you for sharing your experience with us (me). Seems that the sharing of information is infectious and does nothing but bring good will. It has given to everyone a certain amount of power; you are raised up one level as a teacher and I am empowered to understand those around me and what they do when the HR office doors close behind them in the mornings. I am very proud to be involved with these fun loving, beautifully talented people that are HR including yourself. Make no mistake: you have been assimilated.
v/r Peggy

# Posted By prhunnings on Friday, August 15 2008 at 04:02 EDT

4. Very well written, and very true. I had the awesome opportunity to interview with Hashrocket throughout all last week. I think I learned more about software development in those five days than I have in the last year. Excellent team, and excellent people.

# Posted By Matt Darby on Tuesday, September 30 2008 at 03:02 EDT

Add a Comment