Skip to content

Five risks of solo programming

  • strict warning: Non-static method view::load() should not be called statically in /home/artemmarchenko/ 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/ 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/ 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/ 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/ 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/ 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/ 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/ 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/ 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/ 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/ on line 61.

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.

High defect rate

This is the most obvious risk. Human beings are not the magicians and whatever accurate you are trying to be, occasional typos, misunderstanding of requirements and just mistakes are inevitable. Solo programmers fight these mistakes with the help of careful planning, code reviews and various code analysis tools. These activities are definitely useful, but no code review performed after the fact can compare to the continuous code review performed during the act of coding, no amount of careful planning can compare to pairing with the customer, business analyst or tester while working on his requirements.

Pair programming is not a silver bullet, but it is just too risky to assume that a single person can prevent the creation of as many bugs as a pair can.

Distractions that force you out of the zone

Average office worker is interrupted every 11 minutes. No surprise it is so difficult for a programmer to stay in the "zone" and get to the creative and efficient code design. It is not so easy to interrupt the pair working as a team. For people walking through the same office, it is mentally more difficult to dare to interrupt the whole team, pair often shuts down the "individual electronic interrupters" such as the email client that tends to shout about the new message every now and then. Then even if the pair has to be interrupted, often just one person can go deal with the important request and leave the second one in the "zone" to join him after the distraction reason has been resolved.

Pair programming is not a silver bullet, it is just to risky to assume that solo programmers can be as resistant to the external distraction as a pair can be.

Low focus and discipline

Programmers are quite disciplined people, but sometimes there are just very funny commercials shown on YouTube or cool, but irrelevant [to the moment] articles published on a popular web site. These reasons for interruption aren't that bad on their own, after all you cannot creatively code 8 hours in a row. However when this kind of temptation goes out of control, it adds yet another source of distraction. When working in pair, each party naturally feels stronger commitment to the common goal and people can go after the purely private goals after the pairing time slot is over.

Pair programming is not a silver bullet, it is just too risky to assume that a solo programmer can resist the discipline-breaking temptation as efficiently as a pair can.

Low incentive to adhere to common practices

When the deadline is around the corner, it is easy to forget to care about the quality of unit tests, to perform architecture analysis, to verify that the variable names are according to the organizational standards, etc., etc. It is not that easy to admit this in front of your pair. Vice versa, it is much easier to get enough courage to tell the management that a task is too big or to tell your pair, that you just don't know how to apply the certain practice efficiently.

Pair programming is not a silver bullet, it is just too risky to assume that it is as easy for a solo programmer to adhere to common practices as it is for a pair.

Slow learning

Any person entering a team whether he is a seasoned developer or just graduated rookie needs time to learn the team standards, ways of working and the code itself. Solo learning can take months and a shy person might still be not aware of a particular tool usage. Pair programming with a mentor or mentors significantly reduces the amount of time needed to learn the subject area, code and to pick up the team habits.

Pair programming is not a silver bullet, it is just too risky to assume that a solo programmer can learn as quickly as if he was paired with a seasoned team member.

Your risks

What are the biggest risks of solo programming in your opinion? What would you add to the list?

About the Author: As the Editor-in-Chief for, Artem is charged with overseeing the direction for content, advertising, and the overall management of the site. Nowadays in his day life, Artem is a product manager in a global telecommunication company where he leads the development of a product developed in extremely distributed environment. Artem has been applying Agile and researching Agile since 2005. Contact Artem



August 16, 2008 by Artem, 7 years 14 weeks ago
Comment id: 1781

I have a bit of a mental problem replying to Anonymous commenters, especially when you don't know whether these were several people or a single person (maybe I should remove the default "anonymous" name), but in the end I guess skeptics do have a point in requesting the hard data. My personal beliefs and observations might be interesting for some people, but backing them up with the decent study results would make the debate more focused on discussing the ways for mitigating the risks, rather than on discussing whether the risks are real.

I will definitely search the research part of the web and will try proving (or disproving) at least some of these risks some time soon.

It is a very broad topic and

August 16, 2008 by Artem, 7 years 14 weeks ago
Comment id: 1783

It is a very broad topic and very dependent on the concrete circumstances. Therefore, let me touch just several general points (i.e. generalization of my observation of and talks to many teams) in no particular order.

Certainly, how well team is able to embrace agile is very dependent on a lot of factors. In particular there are many ways to do pair programming the wrong way. Some people are even "chemically incompatible" and cannot program together.

It is interesting to hear that you are telling about the agile team producing less defects, but you don't tell whether the defect rate decreases over time. Agile principles call for continuous improvement and good teams (with good coaches) improve over time decreasing the defect rate and improving velocity.

In my opinion Agile methods (or to be precise, the management level of them) aren't focused on producing more features. It is often a nice side effect, but is mostly that - side effect. what [management level of] agile methods is really about is producing *the right features*. High quality and "donness" of every increment allows for getting the customer feedback early and for adjusting the project direction often. As a result you might build less features (though mature agile teams are typically faster, it just doesn't happen overnight), but these features are exactly what the customer needs, not what he told he wants in the very beginning. Pair programming is just yet another vehicle for producing high quality SW. Whether you need it indeed depends on how much you think the built-in quality is important for your organization.

What researchers say

August 20, 2008 by Artem, 7 years 14 weeks ago
Comment id: 1799

Some scientifically valid evidence on the effect of pair programming can be found in this post

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.

Best of