Better Programing Practices: Pair Programming

In previous start-up companies I’ve worked at, it’s been implied that the official development process was something along the lines of Extreme Programming (XP) . In the book Extreme Programming Explained by Kent Beck, it is suggested that Pair Programming is an essential element to effective development with XP. So why is it that none of my managers encouraged pair programming as a regular development practice? I think one reason is that it seems counter-intuitive that a pair of developers can produce more code with higher quality on a single computer than that same pair working on two different machines.

One great thing about starting your own company is that you have more flexibility to experiment, so Clint and I have taken the opportunity to try some pair programming. Our most recent adventure into pair programming was an effort to build a new feature into our top secret project which would enhance usability greatly. The feature (which I’ll likely discuss in a future post) is really hard to implement…. so much so that of our three main competitors, all of whom who have had commercial products for over 5 years, only one of them supports this feature fully. Through careful collaboration in the design process, and then pair programing to turn our design into reality, we were able to get this feature working fairly well in a matter of several days. When I tried to build this feature out on my own previously, I probably spent 5-6 days implementing it and debugging it, with an unacceptable result.

Why is pair programming better?

  • Problem solving – When working on hard problems, two brains are better than one. Often when I would be stuck on a difficult conceptual problem, Clint would have a solution that I hadn’t though of. This kept our momentum going, and allowed us to make rapid progress.
  • Faster Development – When I was at the keyboard, Clint often spotted stupid mistakes I’d made (or visa versa). This allowed us to correct the mistakes before we compiled and tested the code, drastically reducing debugging time.
  • Quality – Having the input of two people during the design process has a tremendously positive impact on your design. Having two eyeballs on the design will help reduce the risk of introducing mistakes, and help increase your chances that you’ll get the best design in place early on.
  • Focus – I literally think the internet is giving me ADD. When pair programming, you are squarely focused on the task at hand. Distractions such as IM or email are less likely since that would be rude to the person you are working with. This intense focus makes a huge positive difference with anything you work on.

I’m sure pair programming isn’t for everyone, but I think we’ve been able to solve hard problems that we wouldn’t have been able to otherwise. While we haven’t decided to make pair programming something we do 100% of the time, I think that whenever we face a difficult problem in the future, pair programming will be the natural choice.

3 thoughts on “Better Programing Practices: Pair Programming

  1. The connector tool was really tough. It was very tricky figuring out how to make sure the orthogonal line would route around other shapes on the stage correctly. I definitely stand by pair programming as a methodology that worked well in this instance.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s