News and Blog

To Pair Program or Not Pair Program? Is that a Question?

February 25th, 2009 » 2 Comments »

Our resident agile activist, wrote about recent retrospectives and some techniques.  We have been pair programming for so long it rarely comes up as a question as to whether we should be pairing or not.  However, we constantly ask how can we be more effective/productive in our use of pair programming.  So we figured we would share some of our thoughts.

Here are items our team identified as reasons to pair program or factors that helped making pair programming easier to do.

Supporting/Driving

  • Instant code review
  • Distributed knowledge
  • Cross pollination (ideas/skills)
  • Higher energy
  • Increased accountability
  • Better focus (less waste)
  • Trust/team building
  • Increased code quality
  • Improved communication



Here are items the team cited as making it difficult to pair program consistently or as detracting reasons to not pair program.

Inhibiting/Restraining

  • Unequally yoked pairs
  • Distractions (phones, laptops, noise, environment, etc)
  • Watching someone else code (boring)
  • High cost to client/lower productivity
  • Fear of being vocal (accountable)
  • Mis-aligned schedules/routines
  • Personality/Hygiene differences
  • Odd number of people
  • Consensus issues



Out of these factors positive and negative the team agreed on some internal standards regarding pair programming in hopes of tipping the positive factors higher than the negative factors and get the most productivity out of pair programming.

Standards

  • Switch pairs regularly
  • Switch drivers (minimum every hour)
  • Small breaks more frequently
  • Identify follow-up information for later study
  • Ask why.  Don’t assume.
  • More distributed skill/experience levels in pair selection
  • Identify strengths to pair appropriate to the task at hand
  • Identify weaknesses and address via books, groups, brownbags, etc)
  • Have empathy for your pair
  • Same person should be solo consistently if uneven numbers
  • Odd man out should be doing research, simpler tasks, etc
  • All unpaired code requires peer review
  • You will be shot if you are without a pair for more than 1 hour



Does your company pair program?  What are your restraining factors?  What are your driving factors?  Do you have standards/guidelines (written or informal) on what is expected of programmers pairing?

2 Responses to “To Pair Program or Not Pair Program? Is that a Question?”

  1. RailsJobs.In says:

    I've pair programmed before. Specifically on bits that were complicated – SQL cross tabulation queries for example.

    Pair programming seems like quite an expensive luxury though. Do you have any ideas on the ROI? Do projects need to be a certain size before pair programming makes sense?

    Incidentally, looks like you have a really cool thing going at Integrum. I'm part of a group of six web freelancers who share office space and work. It's so awesome to have geeks to hack with. Looks like you have the same thing going on over there.

  2. Swedler says:

    I was just commenting today that when I first started hanging around with the Integrum guys I though pair programming was stupid and a waste of one person's time. But I was very wrong. The productivity benefits are so obvious to me now.

    First, you have someone for which you are accountable to, so you don't spend three hours surfing, tweeting, and emailing. Second having a second set of eyes keeps you from spinning your wheels on a problem with blinders on. And lastly, because of the first two, your project gets done far more quickly than a singles.

    I would estimate that a single programmer will take as many hours to complete the work but take twice as long (from beginning date to end date).

Leave a Reply

What People are Saying

"Integrum helped us find creative solutions to some very unique challenges. In one case, we needed a way to quickly and easily provide alerts on our website when buses run late or go on detour, and we wanted these alerts to come directly from our Customer Service Department. Integrum worked with our reps to custom build a tool that gives them control over the info."

— Mike Brady, www.valleymetro.org

Announcements

So…you’d like to work for Integrum?

With a stable of long term clients and growth on the mobile development side as well, Integrum is looking to bring more talented developers to our team.  We’re currently looking for Rails developers from n00b to the cliched ‘rockstar’ level.

We do real Agile (capital A because we don’t fake it) and SCRUM development, so you’ll have to be comfortable talking with clients on a regular basis.  If you’ve got an interest in iPhone or Android development to go along with the Rails stuff, that’s a nice bonus too.

These are full time positions, on-site at our office in Chandler, Arizona. Benefits, perks, Pac-Man, we’ve got all those. Salary is dependent on experience.

Ready to apply? Here’s our job application — a little test.

Below is what you will find in the README for the job application on github.

Please note that these tests all require some basic Ruby knowledge. If you don’t know ruby, take a few minutes to learn the basics. You will need to have Ruby, rubygems, RSpec installed, and Factory Girl installed.
In order to be considered for a position at Integrum, you must follow these steps.

1.    Fork this repository (if you don’t know how to do that, google is your friend)
2.    In the refactor-this directory you will find some Ruby code that needs to be refactored.

  • A test suite is included with failing specs.
  • Please refactor this code, this is real code we found in a real project that could be much more readable and intuitive.
  • Run spec helper_spec.rb to execute your specs and see if they are passing.
  • Please note: feel free to change the specs, but they should all be passing when you turn in your code.

3.    In the github-challenge directory, please create a Ruby script that accomplishes the following:

  • Connect to the github API
  • Find the rails/rails repository
  • Find the most recent commits
  • Print out HTML that groups the recent commits by author.

4.    Add your resume to the resume directory
5.    Commit and Push your code to your new repository
6.    Send us a pull request, we will review your code and get back to you

For more information, contact Chris Conrey at conrey@integrumtech.com or hr@integrumtech.com.

MountainWest RubyConf 2009

We’re sponsoring this years MountainWest RubyConf, March 13-14. Are you going? You should be there – we will be! For more information visit http://mtnwestrubyconf.org/2009/.

Gangplank Hacknight

What is Hacknight? The best way to find out is show up. It is whatever we make it.

Gangplank Academy

Come to Gangplank, same address as Integrum, each Wednesday at 11:45 a.m. for brown bag lunch and a presentation.

Calling all Rails Nerds!

We want you (to work for us)! Drop us a line at hr@integrumtech.com.


Press Room

Integrum wins Small Business of the Year award

How do you know a company deserves an award? When the staff is so focused on going above and beyond for clients, they miss the call from the city notifying them they’ve won.

Fortunately, the City of Chandler was able to track the staff at Integrum down and award them the 2010 Small Business of the Year award at a banquet held last Wednesday.

The 23rd Annual Awards Dinner took place at the Crowne Plaza San Marcos Resort in downtown Chandler. The event celebrates individual and business excellent in the community. Integrum was chosen based on the company’s contributions to the growth of the local economy, high quality service and innovations in the field of software development. Additionally, Integrum was recognized for the company’s community involvement through its nonprofit, Gangplank.

Jade Meskill and Derek Neighbors were on hand to accept the award.

Where We’re At:

  1. Hacknight Every Wed.
  2. Gangplank Academy Brownbag Every Wed.
  3. Boulder Startup Week May 4th-7th

Updates