The Invisible Benefits Of Pair-Programming: Avoiding Wasteful Coding Excursions
The Agile Zone is brought to you in partnership with JetBrains. Learn how Agile Boards in YouTrack are designed to help teams plan, visualize and manage their work in an efficient manner, with support for both Scrum and Kanban processes.
There recently an article was written about how bad, expensive, and wasteful pair-programming is, since you need twice 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 of productivity, actually just the opposite, as I want to demonstrate from my experience. (The article is questionable also for other reasons, such as providing no data to back its claims of a pair 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 data structure 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 mistakenly 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 attractive 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