The Invisible Benefits Of Pair-Programming: Avoiding Wasteful Coding Excursions
There has been recently an article about how bad, expensive, and wasteful pair-programming is, since you need double as many developers. It used lines of code (LoC) produced per hour as the main metric. As many have commented, LoC is not the best measure, actually just the opposite, as I want to demonstrate on my experience. (The article is questionable also for other reasons, such as providing no data to back its claims of a pari costing 2.5 times more without any quality benefits, which contradicts f.ex. the studies summarized in ch. 17 of Making Software that show one1 1.6* cost + better quality, other 1.15* cost + 15% less failed tests.)
My main point is that by working with another person that you have to justify your plans to, you can be saved from pursuing suboptimal or unnecessary solution, thus considerably reducing both time spent and lines of code produced (more talk, less [wasteful] code).
Now to my experience, not the first one of the type.
I have spent over 1 day implementing a "cool idea" - a SQL-like group+select function in Clojure to produce views of my in-memory datastructure so as not to need to access the slow DB. However I have later realized that
If I was pair-programming, I would have had to justify my ideas to my pair who would have likely spotted the faults in my thinking and would have forced me to consider / proposed also other atractive alternatives. (In hindsight, I can think of at least two better ones.) We could thus have easily saved couple of hours and unnecessary lines of codes.
Therefore pair-programming is good even if it decreases lines of code - or perhaps just because of that.
1) The first study is based on 45 min long programming task so there is little opportunity for time-saving by correcting one's wrong course
My main point is that by working with another person that you have to justify your plans to, you can be saved from pursuing suboptimal or unnecessary solution, thus considerably reducing both time spent and lines of code produced (more talk, less [wasteful] code).
Now to my experience, not the first one of the type.
I have spent over 1 day implementing a "cool idea" - a SQL-like group+select function in Clojure to produce views of my in-memory datastructure so as not to need to access the slow DB. However I have later realized that
- It wasn't needed - I could still use the DB directly, because I was mistakingly thinking I need to use the super-slow Hive while I had the data in reasonably fast MySQL (which turned later out to be also suboptimal but pretty usable with little scripting)
- I could have implemented it less efficiently (but who cares?) but much more simply and quickly by combining the existing functions (there is a nice group-on function but it can only aggregate one column while I needed two => call it twice, combine)
If I was pair-programming, I would have had to justify my ideas to my pair who would have likely spotted the faults in my thinking and would have forced me to consider / proposed also other atractive alternatives. (In hindsight, I can think of at least two better ones.) We could thus have easily saved couple of hours and unnecessary lines of codes.
Therefore pair-programming is good even if it decreases lines of code - or perhaps just because of that.
You might enjoy also other posts on effective development.
1) The first study is based on 45 min long programming task so there is little opportunity for time-saving by correcting one's wrong course