1. 7

I was frustrated with the debate about this article on HN – a bunch of people railing on the study. Studying software is extremely hard for reasons we all know. Capers Jones is one of a handful of people actually trying to quantify it. Yes, studies are going to be imperfect but at least they’re trying hard to measure output on a topic that a lot of people are divided on.

I was particularly struck with the comparison with other industries. Many people in other industries work on large systems as well, yet no other field attempts to pair workers together like the software industry.


  2. 5

    I don’t understand… This article calls itself a “study”, but no study was done. The author just made up tables 1 and 2? And then most of the subsequent results came from that?

    Regardless of whether you like or dislike pair programming, If no data was collected to back up these numbers, this “study” is just opinion.

    1. 1

      Wow, good catch. I skimmed right over the part where he said the data in the tables is there because he put it there. Shady.

    2. 2

      I’ve only ever used pair programming in two similar circumstances, but did find it helpful. One is training new employees or interns. Even then, most of the time the code was already written and it was more of a two person code review/debug session. The other time was working with an experienced developer, but also trying to debug and fix some issue that didn’t have an easy explanation. I found it very helpful to have someone else stepping through code and asking questions.

      I would not use pair programming in the general case, however. Watching somebody type is a waste of time.

      1. 1

        I’ve used pair programming once where it made sense, in a situation where we had to get the code right the first time (and even then, there were a few bugs but, fortunately, not show-stoppers). The rest of the time it’s just as problematic as someone constantly walking into my office and interrupting me while I work on something.

        1. 1

          I’ve found pair programming to be useful in very specific circumstances: a.) exploratory programming, b.) bringing a new team member up to speed, or c.) approaching a very difficult problem.

          Shops that practice pair programming exclusively (they’re still out there) seem to be paying two engineers for the work of one.