Skip to content

Category: pair programming

  • warning: Creating default object from empty value in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/taxonomy/taxonomy.pages.inc on line 33.
  • warning: Invalid argument supplied for foreach() in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/cck/content.module on line 1270.
  • warning: Invalid argument supplied for foreach() in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/cck/content.module on line 1270.
  • strict warning: Non-static method view::load() should not be called statically in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/views.module on line 823.
  • strict warning: Declaration of views_plugin_display::options_validate() should be compatible with views_plugin::options_validate(&$form, &$form_state) in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/plugins/views_plugin_display.inc on line 1684.
  • strict warning: Declaration of views_plugin_display_page::options_submit() should be compatible with views_plugin_display::options_submit(&$form, &$form_state) in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/plugins/views_plugin_display_page.inc on line 457.
  • strict warning: Declaration of views_plugin_display_block::options_submit() should be compatible with views_plugin_display::options_submit(&$form, &$form_state) in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/plugins/views_plugin_display_block.inc on line 184.
  • strict warning: Declaration of views_handler_field_broken::ui_name() should be compatible with views_handler::ui_name($short = false) in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/handlers/views_handler_field.inc on line 243.
  • strict warning: Declaration of views_handler_sort_broken::ui_name() should be compatible with views_handler::ui_name($short = false) in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/handlers/views_handler_sort.inc on line 82.
  • strict warning: Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/handlers/views_handler_filter.inc on line 584.
  • strict warning: Declaration of views_handler_filter::options_submit() should be compatible with views_handler::options_submit($form, &$form_state) in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/handlers/views_handler_filter.inc on line 584.
  • strict warning: Declaration of views_handler_filter_broken::ui_name() should be compatible with views_handler::ui_name($short = false) in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/handlers/views_handler_filter.inc on line 608.
  • strict warning: Declaration of views_plugin_row::options_validate() should be compatible with views_plugin::options_validate(&$form, &$form_state) in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/plugins/views_plugin_row.inc on line 61.
  • strict warning: Declaration of views_plugin_row::options_submit() should be compatible with views_plugin::options_submit(&$form, &$form_state) in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/plugins/views_plugin_row.inc on line 61.

Unpublished
n/a

Unpublished
n/a

Pair programming. What researches say on the costs and benefits of the practice.

August 19, 2008 by Artem Marchenko

Photo courtesy of BrianScott@flickr
Last week the entry on risks on solo programming attracted a number of comments debating the value and costs of pair programming (PP). My personal observations and discussions do support the claim of better quality and faster development, when pair programming is done the right way and learned under the coaching of experienced mentor. However, these are just my personal observations and I was rarely focused on measuring and "average" team, most of my observations were based on teams who did want to pursue the path of continuous improvement and were interested in learning how to do the practices the right way.

Gathering data

Anyway, I promised to gather a bit of scientific evidence and here it is. This is not an in-depth scientific review, but rather a result of couple of hours spent on browsing Google Scholar and IEEE Xplore and skimming through the top articles related to "pair programming defect rate" and "pair programming quality". Most of the articles happened to be about the students doing pair programming.  Taking into account the industrial context of original discussion, I decided to ignore most of the articles that involved only students. Note, that for purity I was trying to examine solely the effect of pair programming on quality, defect rate and corresponding costs.

Five risks of solo programming

August 15, 2008 by Artem Marchenko

Woman hiking a slot canyon in the Narrows, Zion National Park  
Pair programming is one of the most debated practices of the Extreme Programming. Historically, programming used to be a solitary activity that required high concentration and even isolation. The best programmers know how to get into the metal state called "flow" or "zone", in which the undisturbed mind is able to efficiently focus on the code and make highly creative and efficient design decisions.

While "zone" is indeed highly valuable and learning how to deepen into zone as a pair might be more difficult, than learning how to get into flow alone, the truth is that despite the comfort of the long time status quo, solo programming is just too risky and in the end might cost quite some more money for the company. There are many risks of solo programming, here are the top five that come to my mind.

XP Practice: Pair programming

April 18, 2008 by Artem Marchenko

Pair programming is one of the most known Extreme Programming practices. In essence it means creating the code in pairs trying to get multiple perspectives on the code created. One of the participants, called driver, types the code and thinks about the low level details. Another one, called navigator, thinks about what the typed code is for. The participants periodically switch roles. The definition of "low level" depends on the skills of the concrete pair and their experience in the subject area. For example, when using test-driven development the driver might be focused on the writing the production code, while the navigator could be thinking about how the next unit test should look like in order to change the system architecture in the desired direction.

Minimize the review burden by applying the review on a smaller bits of code

March 26, 2006 by Artem

Peer code reviews are known friends of a good code quality. Many of the agile methods strongly recommend them. XP as usual goes to the extreme point and offers the pair programming practice, when the reviews are performed continuously.

The usual problem with the code reviews (unless you practice the pair programming) is that they are often performed after writing a big block of code and reviewers can concentrate on the micro level issues like coding conventions and style. It is important to enforce the common conventions, but it would be great to pay bigger attention to the code logic.

Best of AgileSoftwareDevelopment.com