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.
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.
What are the biggest risks of solo programming in your opinion? What would you add to the list?