Pair Programming

Read about a week ago an interesting article challenging Pair Programming

I have to admit the first time I read it it seemed really devastating to pair programming. I however re-read it yesterday when James Nugent sent it by the second time. This time reading through I picked up on something I didn’t the first time.

Table 1 is extracted from a pair-programming calculator developed by the author.  It allows researchers to input a number of variables including staff compensation, application size in lines of code, and coding speeds for both pairs and individual programmers.  Table 1 shows a typical pattern for average pairs and average individual programmers for 1000 code statements

All of the numbers in the paper aren’t actual research! They are assumptions of the author that were then plugged into a “pair programming calculator”. Which as Mark Nijhof pointed out should “really have more than one author”.

In other words even though its on a “research” site and appears professional its just an opinion piece with made up statistics :(

I personally think sometimes pairing is good and sometimes its not. I think the bigger question is getting into a more formal discussion of when it is good or not.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

6 Responses to Pair Programming

  1. Ivano says:

    You can find an essay evaluating the usefulness of pair programming based on research data in the book

  2. gregyoung says:

    btw I would be much more inclined to consider it if the empiric data were there.

    All the numbers there are based on assumptions put into a calculator then presented as research. If the assumptions and calculator were based on actual empirical data it would be very interesting. Without however its just an opinion piece dressed up to look like research.

  3. gregyoung says:

    depends on the problem you are working on. It can be highly inefficient and highly efficient.

  4. Pair programming is HIGHLY inefficient, and by proxy, costly. This doesn’t mean that there isn’t value in doing it selectively. It does mean it’s wrong to do it generally.

    Also do not diminish the works of Capers Jones, he knows what he’s talking about. He’s literally written the book on figuring out software costs. His work is based in empiric data collection, the kind of things that most software developers have never even considered doing or would actively choose to not do.

  5. itoctopus says:


    Have you tried pair programming before? In our experience it has a server hit on productivity and it’ll increase the cost of our services. We cannot afford it and we don’t even think it’s good.

    I read the post you mentioned and I can attest to its data – I never measured them but I think they’re very close to reality.

  6. Calvin says:

    The fundamental flow with the paper is the reliance on LOC as part of the metric

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>