Five risks of solo programming

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?

14 thoughts on “Five risks of solo programming”

  1. There is one basic problem with pair programming: Two people working together cannot produce as much commercial output as one person. Commercial realities, especially when heading into recession, are more important than the items you list above.

    1. You say that there is a higher defect rate for single programmers. I would like to see the evidence of this. Possibly there would be a 75% higher defect _count_ if the two people working together but not paired were also producing 75% more output?

    2. This is pure bunk. The developer is not the average office worker. If, as a manager, you allow this type of interruption then you are an idiot, particularly if your team is large enough to permit pairing.

    3. Low focus and discipline. Are you kidding? Good developer are amongst the most focussed people I know. However, everyone needs a break a few times during the day and, from my experience, the breaks are longer when there are two people playing on the Internet together.

    4. I don’t know how to answer this one. It seems like an addition because you were struggling to hit five reasons.

    5. This is almost 4 again. However, I see no difference between the solution provided by pairing or a similar solution provided by mentoring within a team. In fact, a pairing with another developer with bad habits could be more damaging than a general concensus with a team.

    This article is arse gravy of the worst variety.

  2. I agree with most of your article .. although I think your last two points ( low incentive to adhere to best practices and slower rate of learning going solo ) are probably your best.

    The guy who titled his post “commercially naive” is absolutely mistaken when he says that a pair cannot produce more commercial output than a solo developer. It may look that way at first .. but not later when the pair has a cleaner design and less insidious bugs to try and dig out later. Over the entire development cycle, the pair catches up and wins the “output” race.

    Good post.

  3. In response to the “Your last two points” poster.

    Where do you get your data from? I would agree that *A* pair can produce more than *A* solo developer. However, my data shows that *A* pair produces substantially less that *TWO* solo developers, particularly if those solo developers are on a team.

    Yes, occasionally a pair will spot an error as it is typed. However, these tend to be typos and simple errors. The more complex errors that can creep into software are probably found more quickly by a pair than a solo programmer. However, twice as quickly? I think not.

    Personally I believe that pair programming is one of those fads that some people (though not the post’s author I note) believe is a magic bullet. I would fully expect it to be replaced shortly as most other things have been.

    I would certainly be getting concerned by the world economic climate if I were a pair programmer right now. I know of several companies that are already slashing their developer numbers and I think that many others will follow suit, possibly by halving those pairs…

  4. 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.

  5. One commenter in this case (for my previous two comments).

    I would certainly like to see hard data. The evidence I have gathered through monitoring the teams in our business, which has recently merged and contains an agile group (TDD, pair-programming, etc.) and a non-agile group. Over the past eight months, I have noticed the following:

    The agile group produces less defects in the same period of time. However, the non-agile group produces far more software. This seems to give roughly the same number of defects per “unit” of code.

    The non-agile team makes more money per developer. Substantially more in fact, given figures ofapproximately 125% more per person is terms of monetary value. That is, for every Euro that the agile team make in turnover (not profit), the non-agile team makes 2,25 Euro.

    I have seen that the agile team are able to begin coding more quickly than the non-agile team, who prefer big upfront design. For small developments, the agile team are able to respond more quickly but for large software, the agile team tend to flounder and the non-agile team respond more quickly and with better accuracy. They believe this is due to the solid, rather than evolved, design that they have and due to this design being available on paper where the non-agile team have less documented design.

    The upshot is that in the current economic climate, we are looking to make redundancies. It is looking likely that we will be losing 40 of the 105 developers that we have. It is very likely that most, if not all, of these will be from the agile team because they provide the business with the least value individually.

    One last point. I am from the business that had the agile team and I am a huge proponent of the agile manifesto. I have had my eyes opened by coming into contact with the non-agile team from the business that purchase our company and I am now questioning our practices in a commercial environment. I am also part of the manergerial team that will be making the cost-cutting measures, hence the anonimity.

  6. 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.

  7. …but at what cost?

    There are other issues besides “defect spotting” that must be taken into account, too: having two heads working on architecture issues is almost *always* better than one. Looking ahead to the “hit by a bus” scenario is also invaluable, even if no bus is actually ever involved. The issues spotted are usually of greater import than a simple typo.

    Call it cargo-cult as much as you’d like, but taking a narrow view of the benefits is doing a disservice.

  8. It’s nice to be reminded that agile is not a silver bullet, that it can fail. I am wondering why it is failing in this case.

    How many agile developers are there and how many teams? Were you using Scrum or XP? How do your teams score on the Nokia Test? What impediments have the teams identified and were they able to resolve them? Why is agility considered the reason for the lack of success of the product? What other factors contributed to the lack of success?

  9. … longer. I just finished funding about 1000 hours of work by a single developer. When the work was done, we discussed the solitary effort. The programmer expressed he has no ‘sounding board’. We discussed the issue in detail.

    Pairing works, small teams work. I now believe the best team size is 3 developers minimum, ideally with 1 tester.

  10. The article and the ensuing comments are thought-provoking. Those of us working as freelancers have no option but to code solo, and it is true that there are occasions when you wish you had a coding partner to discuss complex problems with or ask him to inspect your code to locate those-hard-to-spot bugs. I sometimes spend countless number of hours chasing a bug that in the end turn out to be a simple typo. If you have to de-bug your own code by yourself, you tend to overlook many errors another person would have spotted instantly. That is one of the perils of working solo but it can be overcome.

    However, the reason why having pair of programmers are better than one working solo is when you are doing the architectural design. Solo developer may take a longer route to implement the application while someone else can point out a short cut, reducing the number of hours the task takes significantly, not to mention the qualitative improvement of the code. So, as someone commented above, if you are after a quality, hire two people if else go solo and thus reduce overall cost of the project. While two brains working on same problem tend to find answers quicker, the cost to the employer is double. Whether the benefit gained is equally double, I am not so sure.

  11. Well i think pair programming is a overhyped thing in the later article you told about not prising as as the silver bullet but acutally you do.
    First time i did pair Programming in 1991 or something when i modifed the q basic gorilla game together with my little brother. It is just logical if somebody can not solve it alone he might do it with somebody together, or your project manager is telling you ‘could you do this part together with your colleague’

    In a good Team with a nice culture it happens automatically,
    well in a buzzword company where everybody works on hos own and tries to be the supercoolest you can go to your boss and tell him, i am so cool i read about this new supercool hype technique it is called pair programming we should buy a book about it, make an exam and use it for everything.

    all arguments can be used in both ways,
    1. Defect Rate
    well allone you have to care about anything yourself in a pair, maybe the other one could (not) do. “I were not taking care of that issue, i thought you were always taking care of that ?”
    2. Distractions
    however if there talking 2 persons it is a bit more difficult to distrub them but the chance that one of them is needed is twice as high that one of them is needed.
    However maybe forward all codes to a secretary or team assistent would make more sense.

    3. Low Focus & Discepline
    Well even 2 people can focus on something else like general exchange about the newest post on a site or anything else. The developers discipline will even decrease a lot more if you force him to work together with these ugly other guy who didnĀ“t had a shower and had a lot of garlic sauce last night.

    5. Slow Learning
    well if somebody is new in a team, it s just some usual thing that u ask other team members, well at well written and documented software you need to ask perhaps less,
    of cause it can help you if you look over somebodys shoulder or he over yours,
    specially if there is a skill difference you can have benefits on both sites.

Leave a Reply

Your email address will not be published. Required fields are marked *