We admit it, Cloudspace made a mistake. We got pair programming wrong. We did it with the best of intentions, but our plan completely backfired. Let me explain...

We have been using versions of Agile Development at Cloudspace for most of our 13 year history — even before it had a formal name. However, we didn’t implement pair programming, or extreme programming (XP) as it is sometimes called, at the company until more recently. One of the driving factors for moving to pair programming was the rapid growth of our business working with tech startups. In order to serve these clients, we needed to grow the team rapidly. As we started discussing options, implementing pair programming came up. Pairing junior developers with more senior developer on the team to mentor them through on the job training sounded like a good idea. In fact, we thought this was so much of a good move that we carved out specific team roles for Jr. Developers and Pair Leads.

Guess what? It didn’t work.

The “Pair Leads” got frustrated trying to bring the junior guys, good developers with Comp-Sci degrees and industry experience, up to speed on our system of development. And the junior guys weren’t learning half as fast as we hoped. In fact, they weren’t learning half as fast as they did with the old non-pair programming system. We tried a few things to improve the process overall, but nothing seemed to work. Unfortunately, compared to computer systems, debugging people issues are very hard. But sometimes, you guys get lucky.

In a conversation last week, Steven Covey’s book The 7 Habits of Highly Effective People came up. I can’t remember how or why this came up, but I’m glad it did. The person I was talking with said that they tried to read the book but gave up because it felt dated. I hadn’t read the book since business school, but could still remember quite a bit of subject matter. I started spouting them off a few of the habits (as best I remembered them):

Sharpen the saw.

Seek first to understand, then to be understood.

Then I said:

In order to be interdependent, you must first be independent.

I said it and I just froze. That was it! We were trying to throw junior guys who were not first independent working in the Cloudspace system into a pairing relationship which requires two highly effective developers to work interdependently. We totally blew it and now I knew why.

When used properly with skilled engineers you can’t beat pair programming for solving hard problems; creating high quality code; and, as Covey would said, making 1 + 1 = 3. But it is absolutely the wrong way to get junior developers trained.

Hindsight being 20/20, I now see the two types of pairing as 180 degrees from each other. When highly effective developers pair program the conversation is around system performance, best practices, tech trends — discussions of craft which often break into passionate arguments about the best way to achieve an objective. When one of the developers is not yet up-to-speed, the discussion is completely different and easy to spot. This type of pairing primarily involves discussion of syntax, improving skills, following processes & procedures, “let me do that for you to save time.” Basically, anything but craft is discussed. Yes, pair programming helps keep the developers focused and catch errors at every skill level. But I no longer believe that this is worth using pairing as a form of training.

So where do we go from here? At Cloudspace we are now re-tooling our training (we have some very cool stuff in the works on this front), ongoing developer development, and career paths. New recruits will go through training and then work independently on simple projects that really shouldn’t need pairs — all while receiving a high level of feedback; especially in the form of code reviews. They will only graduate to pair programming after they have demonstrated a basic level of mastery of their craft. (One member of the team has suggested that we bring developers into a dark room with tiki torches and read their fate from slips of paper written by senior developers Survivor style; but we aren’t there quite yet.)

Overall, we think that Cloudspace will be much better for making the change. And, as always, we wanted to share our thinking and screw-ups as publicly as possible so that everyone else can learn from our mistakes. Hope this one helps.