Pair Programming in the New York Times

Dietrich Kappe, Monday, September 28, 2009 @ 3:26 pm

photo credit: albany_tim

When scientists and engineers explain their esoteric disciplines to the general public, they reach for analogies. Sometimes those analogies are apt and serve to clarify what is hard to understand, sometimes they are less apt and serve to obfuscate and confuse. We certainly use our fair share of analogies in software development -- construction, manufacturing, brain surgery -- and some of them, especially the one to construction, have been very harmful.

So when I saw the article in the NYT this past week on pair programming, I started counting the analogies.

1. First there was the implied analogy of the title: the "Buddy System," commonly used in safety critical situations where two folks look out for each other.
2. Next there was the colorful "Where's Waldo" analogy where Waldo was a bug, and the artist producing the drawing was the programmer writing the software. His pair was then easily able to detect "Waldo" early on in the drawing of the picture.
3. Programming is like creative writing where you can get writers block.

I generally like to describe things in positive terms, but this was pretty weak stuff. I think that Pair Programming and TDD are the two most important practices in Agile Software Development, and even I was having second thoughts about using it after reading this article. In order to get the full measure of what pair programming gets you, I think you have to look at what singleton programming sticks you with.

1. With singleton programming you have a bus number of one on lots of your code, i.e. only one person knows a certain system and when a bus hits them, you're screwed. Think of all of the times you've said something like "Oh, the reporting system? Joe knows that. We have to give that to Joe to develop." That's your project telling you it's in jeopardy.
2. With singleton programming, most of your developers slack off. They browse the web, they check their 401k, and so on. Walk the floor of any large development cube farm and you see a ton of this. Walk the floor in any Agile shop that practices pair programming and you see design and code being produced.
3. With singleton projects you have to schedule code reviews, because your code is only as good as your weakest developer. With pair programming you have code reviews happening all the time and the pair is as strong as the stronger developers (and the weaker one learns from the stronger).
4. With singleton programming, developers can become distracted or discouraged. They can hide the fact that they are making no progress or blocked by an obstacle. With pair programming these sorts of moral problems and surprises are far less common. Two developers are generally much happier and confident than two singletons.
5. With singleton programming you have lots of time wasted in ramp up and knowledge transfer tasks when developers join and leave a team. It's related to #1, but it's a little bit different. It's not catastrophe; instead its a reluctance to add or move resources as the project dictates. Once the project is running, changing the team size or composition is a major undertaking.
6. With singleton programming, two developers working apart are less productive than two developers working together (fact!).

There are many more things that singleton programming sticks you with, and I think it's clear that the question isn't "why use a buddy system," but rather, "why would you every have developers working alone?"

Related posts:

1. Pair Programming: Lone Programmer Shoots Back
2. The Importance of Pair Programming
3. A Pair of Kings Beats A Single Ace: Pair Programming, Agile Rails, and You
4. Pair Programming with VNC
5. Growing Into Pair Programming

Comments (5)

Software Development

Comments: 5 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   It is amazing how insulting people can get when waxing on about the benefits of Pair programming. It is one thing to make the business case to an organization that Pair programming can be beneficial to an organization, but it becomes downright mean when developers get classified as being lazy because they are not paired up. As someone who has spent many a night working (alone) for as long as it takes to complete a project on time without anyone noticing, I seriously disagree with the notion that by not pair programming, developers are lazy.

   I also do not understand what the obsession is with that retarded “Bus” analogy. I’ve heard it over and over and over again and rarely have I ever found it to be true. I’m not saying that it is not true because no one ever gets hit by a bus (sure, it could happen), but because it is rarely the case that a developer will leave suddenly as if they were hit by a bus. When core talent leaves an organization it is because the organization is not able to hold on to an essential asset. Management rarely ever likes to acknowledge being the cause of someone leaving. If someone is an expert within a subject and is constantly assigned to the same type of work, that is a flaw of management not trusting a developer to work on something else out of fear it might take too long.

   What ultimately boils my skin about things like pair programming is that it is the sort of thing that niche companies expect as a requirement for employment. Software development is such a fragmented industry that someone with valuable skills gets ignored because there is no common comparison between a developer with one skill set and a developer who has experience with something entirely different.

   Comment by Nathaniel Anthony, Monday, September 28, 2009 @ 7:23 pm

2. 

   Hello,

   The Pathfinder blog is a great source of interesting opinions and informations.

   However when making bold statements like “two developers working apart are less productive than two developers working together (fact!)”, it’s better to either reference some studies or to leave out the “(fact!)” which doesn’t add much credibility to the statement (a bit like “not lying, I promise!”).

   A quick googling gave
   http://portal.acm.org/citation.cfm?id=1161678
   and
   http://www.springerlink.com/content/mpv6y08254rqw98h/

   Besides that detail, keep the great posts coming
   Maxime

   Comment by Maxime Robert-Schreyers, Tuesday, September 29, 2009 @ 1:34 am

3. [...] got a few angry and scolding comments on my last post on pair programming. Let me address each of the issues in [...]

   Pingback by Pair Programming: Lone Programmer Shoots Back | Pathfinder Development | Software Developers | Blogs, Wednesday, September 30, 2009 @ 2:38 pm

4. 

   Funny thing: That piece could have been written about pair programming AT The New York Times. We do it all the time in my group. I agree (in small part) with Nathaniel that the benefits can be overstated, and taken too far. But good vastly outweighs the bad.

   Comment by Aron Pilhofer, Monday, October 5, 2009 @ 6:17 am

5. 

   Don’t worry about the naysayers. Too much navel gazing is prevalent in this industry. Too much time is spent down a rabbit hole chasing a go nowhere solution. No matter how many code reviews you do, you’ll still have as many coding styles in your projects as you have devs. Too much bad design and code goes unnoticed.

   What pair programming does not allow equates to 10x the productivity, not 30% or 50% that the short sighted “how many feature points can a pair hack out vs single dev” experiments yield.

   Until the Nathaniel Anthonys of the world “get it” we all have a lot of money to make as consultants taking companies out of projects gone bad. I don’t think that’s any time soon. Bring on the next version 5 disaster…

   Adam

   Comment by Adam D., Friday, October 23, 2009 @ 6:05 pm

Leave a comment