[Here's another one that I missed the Reply-to-All on] That sounds really interesting. :-) I read that article, and it seemed like an interesting start.
If I remember their hypothesis correctly, it was that the protocol of pair programming overcomes the natural inefficiency of people working separately on the same thing. So, moving beyond the concurrency metric into possibilities of measuring pairs (and I'm just sort of thinking out loud here), do you have any ideas on how to detect whether two people are acting as a pair? I guess you wouldn't need to, since they'd be at one keyboard and have a single telemetry stream. This leads me to something I've wondered about for a while with tool support for pair programming. Most tools, like version control, are hard coded to one user. When the build breaks, and the continuous integration environment looks at the most recent checkin to send a "blame" or "break" email, it can't know that two people worked on that one file and were responsible for checking it in. Subversion has an interesting feature. It allows you to to associate properties with files. That's usually used to flag a file as binary or something, but it can be arbitrary. It also allows you to associate properties with a particular change set, or checkin. This is where they store the author. You can add custom properties there too, so a simple script could allow you to place a second property on the revision/change set. It's possible, doesn't change any Subversion code, but could it be done unobtrusively? I don't know. >From the Hackystat perspective, how would you indicate that two users are sharing a keyboard? How would you know when they stopped and forgot to tell the program they split up? How would you measure the active time? One stream for each with the same data? That would make the sums come out correctly. I think an important part of correctly understanding the dynamic of pair programming is proper tool support to gather accurate information. The concurrency telemetry stream is very interesting indeed, and it would be interesting to discover a way to take metrics on pairs. Anyway. Just some random thoughts. --Tim On Sat, 18 Sep 2004 08:36:24 -1000, Philip Johnson <[EMAIL PROTECTED]> wrote: > In the September/October issue of IEEE Software, there is an article > entitled "A field study of developer pairs: productivity impacts and > implications." This study talks about some prior research by the authors > where they correlated a "concurrency metric" (which is basically calculated > as the number of developers working on the same module in the same day) to > some sort of productivity metric, finding that developers working alone > were significantly more productive than those working together. They then > tried to rationalize their research with pair programming, which would > appear to contradict their prior findings. > > The concurrency metric would be an interesting thing to provide as a > DailyProjectData/Reduction Function/Telemetry Stream. We could build on > the existing research in a couple of ways: > > 1. Try to replicate their findings, and see if we see the same effect on > some proxy for productivity. > > 2. Try to extend the research by looking for the impact of the concurrency > metric on other facets of development--test cases, builds, reviews, etc. > > Cheers, > Philip > >
