So a little background about me. I've been developing software in the back bedroom for many years, along with my brothers. Worked for a dozen different companies in varied team sizes, on many successful projects over the past 8 years. So I would consider myself pretty experienced (Games, Applications, Web Applications, C++/Assembly/Flash/PHP etc. you get the idea).

So now, on my most recent contract. The most highest paying one I've ever had, a very important UK project, but arguably one of the more easier projects I've been involved with, and working alongside generally less talented developers than most of my previous roles. I've come across this new buzz word called "Pair Programming" (PP).

Now I'm not sure how I've managed to avoid PP for so long in my career. But apparently, PP is not only the solution to improving code quality, but is apparently the only way any good software was ever built, and any project that has been successfully developed without PP is a miracle.

(I personally think considering the importance of the project we're working on. We should take the hiring process more seriously and hire quality developers i.e. nerds. over hiring 'politically savvy' sub-standard developers and coming up with various processes to improve their output on such an important project.)

*end of rant*

Now looking at this objectively. If I do a google search for PP. I can see a lot of studies that report PP to be more productive, improve code quality, and reduce bugs. I can't understand this when most programming tasks are trivial (or at least seem trivial to me). Once the architectural aspects of a task have been discussed. A good programmer should be competent enough to implement the architectural specification. Then once implemented, another developer should be able to code-review it, just to pick up any small programming mistakes (not architectural mistakes as that has been cemented before coding).

Looking back on an old topic on GameDev.net about PP, seems mostly negative views on it. Perhaps GameDev.net developers have a different view, or perhaps the majority of developers have a different view, and these studies are skewed?

I think the problem is that in most projects. There are 10-20% of programmers that are truly talented and motivated. They are responsible for the core, and even much of the bulk of any software project. The other 80-90% lack talent and/or motivation and don't contribute much (especially when you factor in the number of bugs, and hacks they introduce). PP works well for them.

"I find with PP I'm much more productive" - Perhaps thats because when you work alone, you're not focused, and browse the internet most of the time. Or perhaps thats because you're not as good as your pair, so your output is being raised (perhaps your "better-half" is less productive - assuming he is motivated on his own).

"I find with PP we spot errors like semicolons, and brackets more quickly" - Missing semicolons and brackets is simply unacceptable. If you make these silly mistakes shame on you. If it takes you a long time to spot them after the compiler has helped you find the line, then well I think you need to find new profession.

"I find with PP we come up with different solutions to solve a problem" - No, discussing how you're going to tackle a task gives you different solutions to solve a problem, this is architectural design. If you have discussed a problem properly before writing a single line of code. Then there are very few ways of implementing the code, especially once you follow an agreed upon coding standard/convention.

"I find with PP I learn lots" - You can also learn a lot just by reading or reviewing the code, instead of interrupting someone's train of thought. I actually find I learn much better by playing with the code, figuring out how things work and developing a complete map of the code base, instead of relying on someone else to tell me all the answers.

"After a long day with PP I feel satisfied" - This is very interesting. Considering programmers tend to be introverted. I find programming solo, very therapeutic, and I can code into the evening with people reminding me to go home. Makes you feel pumped and really good about yourself. With PP, I start to get a headache in the afternoon, and just want to go home. It's painful, emotionally draining. - I don't consider myself that introverted, I enjoy talking to people, helping them with problems, and chatting up the female staff. I just don't enjoy pair programming. I feel like an impatient kid jumping up and down watching a programmer slowly write code, and constantly correcting them, and trying to convince them to do it my way.

It probably is a case of talent and motivation. I've done a lot of pairing with others over the past 6 months. But when I think of all the times when I've paired with other people. I've felt that it would've been of better quality on my own (they disregarded certain safer techniques that I would've used), and done quicker (they seemed tired, and not properly focused). While they felt that they produced better quality code with me, and that they were productive.

(Weak Programmer + Good Programmer) / 2 = Average Programmer.

(Lazy Programmer + Motivated Programmer) / 2 = Average Programmer.

In closing. I have a habit of checking the git blame (or svn annotate) whenever I see some pathetic excuse for code (dirty copy and paste, badly named variables, not following code conventions, lazy hacks etc.). So I can tell the programmer what I think of his work. However, many a time, I've done this, and to my surprise I discover that the work was paired on (in the comments we mention the initials of who we paired with on the task). So I'm not convinced that pairing is the solution to improving code quality. Finding decent programmers is the best solution (which requires a combination of good pay, and more importantly good interview and selection process). Perhaps our education system is swamping the software industry (especially big companies) with graduate programmers who are neither motivated or up to the standards of the older generation of back-bedroom programmers.

It could also be that I'm not much of a team player :D - Although I actually enjoy discussing and planning things with others. I'm just old fashioned in that I like to do the work on my own.

Coming soon: Quad programming, the only way real software is made.

("We tried making a hello world program, and were scratching our heads trying to find out why it wouldn't compile. My number 2 couldn't smell it. Number 3 suggested reading the error message, thats what his iPhone says. Number 4 guessed it was a pesky semi colon...")

Pair-programming is effective primarily when used with foresight in a per-case situation.

There are times when I work best alone, as should be true for all of us over half the time to varying degrees.

But in some cases I need to implement an algorithm into an existing code base and I am not very familiar with the code. Pairing up with someone who knows the code base is quite efficient.

I explain and code the algorithm or feature while asking, “Now I need the part of the code that handles this,” and he or she quickly directs me there, explaining any caveats I need to know before proceeding.

As with most things, it’s usually only “purely bad” because it is not being used properly. If utilized correctly it does have a good side.

L. Spiro

So a little background about me. I've been developing software in the back bedroom for many years, along with my brothers. Worked for a dozen different companies in varied team sizes, on many successful projects over the past 8 years. So I would consider myself pretty experienced (Games, Applications, Web Applications, C++/Assembly/Flash/PHP etc. you get the idea).

So now, on my most recent contract. The most highest paying one I've ever had, a very important UK project, but arguably one of the more easier projects I've been involved with, and working alongside generally less talented developers than most of my previous roles. I've come across this new buzz word called "Pair Programming" (PP).

Now I'm not sure how I've managed to avoid PP for so long in my career. But apparently, PP is not only the solution to improving code quality, but is apparently the only way any good software was ever built, and any project that has been successfully developed without PP is a miracle.

(I personally think considering the importance of the project we're working on. We should take the hiring process more seriously and hire quality developers i.e. nerds. over hiring 'politically savvy' sub-standard developers and coming up with various processes to improve their output on such an important project.)

*end of rant*

Now looking at this objectively. If I do a google search for PP. I can see a lot of studies that report PP to be more productive, improve code quality, and reduce bugs. I can't understand this when most programming tasks are trivial (or at least seem trivial to me). Once the architectural aspects of a task have been discussed. A good programmer should be competent enough to implement the architectural specification. Then once implemented, another developer should be able to code-review it, just to pick up any small programming mistakes (not architectural mistakes as that has been cemented before coding).

Looking back on an old topic on GameDev.net about PP, seems mostly negative views on it. Perhaps GameDev.net developers have a different view, or perhaps the majority of developers have a different view, and these studies are skewed?

I think the problem is that in most projects. There are 10-20% of programmers that are truly talented and motivated. They are responsible for the core, and even much of the bulk of any software project. The other 80-90% lack talent and/or motivation and don't contribute much (especially when you factor in the number of bugs, and hacks they introduce). PP works well for them.

"I find with PP I'm much more productive" - Perhaps thats because when you work alone, you're not focused, and browse the internet most of the time. Or perhaps thats because you're not as good as your pair, so your output is being raised (perhaps your "better-half" is less productive - assuming he is motivated on his own).

"I find with PP we spot errors like semicolons, and brackets more quickly" - Missing semicolons and brackets is simply unacceptable. If you make these silly mistakes shame on you. If it takes you a long time to spot them after the compiler has helped you find the line, then well I think you need to find new profession.

"I find with PP we come up with different solutions to solve a problem" - No, discussing how you're going to tackle a task gives you different solutions to solve a problem, this is architectural design. If you have discussed a problem properly before writing a single line of code. Then there are very few ways of implementing the code, especially once you follow an agreed upon coding standard/convention.

"I find with PP I learn lots" - You can also learn a lot just by reading or reviewing the code, instead of interrupting someone's train of thought. I actually find I learn much better by playing with the code, figuring out how things work and developing a complete map of the code base, instead of relying on someone else to tell me all the answers.

"After a long day with PP I feel satisfied" - This is very interesting. Considering programmers tend to be introverted. I find programming solo, very therapeutic, and I can code into the evening with people reminding me to go home. Makes you feel pumped and really good about yourself. With PP, I start to get a headache in the afternoon, and just want to go home. It's painful, emotionally draining. - I don't consider myself that introverted, I enjoy talking to people, helping them with problems, and chatting up the female staff. I just don't enjoy pair programming. I feel like an impatient kid jumping up and down watching a programmer slowly write code, and constantly correcting them, and trying to convince them to do it my way.

It probably is a case of talent and motivation. I've done a lot of pairing with others over the past 6 months. But when I think of all the times when I've paired with other people. I've felt that it would've been of better quality on my own (they disregarded certain safer techniques that I would've used), and done quicker (they seemed tired, and not properly focused). While they felt that they produced better quality code with me, and that they were productive.

(Weak Programmer + Good Programmer) / 2 = Average Programmer.

(Lazy Programmer + Motivated Programmer) / 2 = Average Programmer.

In closing. I have a habit of checking the git blame (or svn annotate) whenever I see some pathetic excuse for code (dirty copy and paste, badly named variables, not following code conventions, lazy hacks etc.). So I can tell the programmer what I think of his work. However, many a time, I've done this, and to my surprise I discover that the work was paired on (in the comments we mention the initials of who we paired with on the task). So I'm not convinced that pairing is the solution to improving code quality. Finding decent programmers is the best solution (which requires a combination of good pay, and more importantly good interview and selection process). Perhaps our education system is swamping the software industry (especially big companies) with graduate programmers who are neither motivated or up to the standards of the older generation of back-bedroom programmers.

It could also be that I'm not much of a team player - Although I actually enjoy discussing and planning things with others. I'm just old fashioned in that I like to do the work on my own.

Coming soon: Quad programming, the only way real software is made.

("We tried making a hello world program, and were scratching our heads trying to find out why it wouldn't compile. My number 2 couldn't smell it. Number 3 suggested reading the error message, thats what his iPhone says. Number 4 guessed it was a pesky semi colon...")

You are forgetting a few things though, less experienced programmers learn alot while paired up with a more experienced developer and the experienced developer will improve his teaching skills at the same time (This is very valuable to a company in the long run), On large complex projects it is very hard for any single developer to be an expert on everything (and even if you have a company filled with übergodprogrammergurus they still won't be familiar with every part of a large codebase), pairing helps spread knowledge within the company. If the programmer who wrote your <insert component or system here> gets sick, quits etc. it really helps to have other people in the company who are familiar with the work he has done.

Pair programming isn't primarily for your benefit or your partners benefit, it is for your employers benefit.

Thanks for the responses. I would like to apologise for the wall of text in the original post. I wanted to rant, but also focus on making mostly objective. But alas I'm very passionate about programming, software and especially the currently project I'm working on, and got a bit carried away.

Yes, I think the problem with our project is that the chief proponents of pair-programming are the Scrum Masters (who have no technical experience, and zero programming experience). I feel that many of the developers are political brown-nosers, and don't really care about the project beyond following the Agile process & whatever the mighty Scrum Masters decide (as they are responsible for the hiring & firing).

They are suggesting that we should all pair 100% of the time during a sprint. I feel this is simply not practical, and is a massive waste of resources. Most programming isn't rocket science, and companies should be hiring people that are qualified to write decent code. This latter point I think is the problem.

The only real benefit I can see from pair programming (that can't be gained so well from code-reviews, and just calling someone over 5-10 mins to explain something to you), is that of training/mentoring someone less experienced. For this, it must be established before pairing, not who is the Driver & who is the Navigator. But who is the Student, and who is the Teacher.

I simply feel, and I may be wrong. I'm just the 'programmer' after all, no one tells me the big picture. That if you have a project which is so important, which you simply cannot afford to mess up. You shouldn't focus your efforts on training graduates, leave that for another team. You should be hiring the best in the industry, and let them focus on priority number 1, which is delivering a kickass product!

I find I can just read code to learn new ideas and approaches to problems. Only thing I learn from pairing with someone else is: How fast they type, what keyboard short-cuts they use/don't use, how often they are distracted, their thought processes. If I were the project manager, then it might be useful, as I could find out who were the effective programmers and who were not. But I could just review all the patches submitted over a period of say a week to see how much work people were doing, and the quality/complexity of the work. (unfortunately our Scrum Masters are clueless to the output of their workers, if they knew, they would almost certainly abandon Pair Programming).

---

In terms of gains to the employer. This is another interesting topic. The question over is it better to have everyone working on everything. Or people that specialise on certain components...

With the former: The advantage is that everyone knows a little bit about everything.

With the latter: The advantage is that everything has someone who is an expert.

From my experience, and my current employer has also come to the conclusion that the latter is far more beneficial.

In theory it's good for everyone to know about everything in case someone is busy on something else, away, or leaves the company. However, in practice this is rare. You might lose an expert every 6-12 months, depends really on the project. - I think a lot of developers leave projects because they have no attachment to it. They don't feel they own anything in the cluster-**** of components.

In practice what happens is that no one knows enough about any single component to be confident enough to know what will happen if you do this or that. No one has a complete mental map of any component. You can't properly work on a component, without knowing what *EVERY* line of code inside that component does. Sure you can add an extra function here, or a little bug fix there, achieving a task now. But what happens is that over time, there are lots of ugly extensions, hacks, and bug fixes, that makes the code unmaintainable, because no one can see enough of the forest to say "Hey there is already a SetTextToRed written by Jim, SetTextToGreen written by Jack, and I'm writing a SetTextToBlue function, why not just have a SetTextColor function" - of course that's a simple and obvious refactor that anyone should see, in practice they're a bit more complex than that. But these are the things that are missed when you have no component ownership.

The most bug-riddled code is in the code which is old, has had a lot of modifications over time, and has been worked on by a lot of people. I love git-blame, it tells an amazing story about the code you're looking at.