Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Invisible Benefits Of Pair-Programming: Avoiding Wasteful Coding Excursions

DZone's Guide to

The Invisible Benefits Of Pair-Programming: Avoiding Wasteful Coding Excursions

· Agile Zone
Free Resource

Speed up delivery cycles and improve software quality with TestComplete. Discover the most robust automated testing tool for end-to-end desktop, mobile, and web testing. Try TestComplete Free.

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

  1. 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)
  2. 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

Release quality software faster with TestComplete. Discover how to decrease testing times and expand test coverage with the most robust automated UI testing tool. Try free for 30 days.

Topics:

Published at DZone with permission of Jakub Holý, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}