Pros and Cons related to Pair Programming

Question

Our company has gone through some changes and the new CIO wants to present a case to the other boss about pair programming.

I do not have any experience (zip, zero, zilch, nada) with pair programming (which makes this presentation much more FUN). What parts would you highlight in a presentation to upper management?

How is this different from... one developer writes code, checks it in to SourceSafe, another developer checks it out and modifies that code file?

If you have done pair programming, what are the pros and cons of such an environment?
Any personal preferences?

Answer 1

Pros:

• Two pairs of eyes catches errors, potential better design, etc.
• One can concentrate on thinking while the other is busy with typing.
• Good opportunity to share information, skills, techniques etc.
• Should result in cleaner more maintainable code long term.

Cons:

• Can be more tiring or annoying
• Takes a while to get used to it and good at it.
• Not suitable for everything, a lot of mind-numbing boilerplate is better of done alone etc.
• Can slow things down by as much as 50% in the short term.
• Some people just don't like it.

Answer 2

I enjoy doing paired programming because when you are talking through what you are doing and having to explain it in your own mind it becomes much clearer exactly what your aim is.

It can be good if one of you writes the test and the other fulfills the assertions in the test and take it in turn to do this.

I find that if someone is watching me / working with me and discussing what we are trying to achieve in the code (apart from making more ham handed keyboard mistakes) that the quality of the code is better, the test coverage is better and there are less silly little mistakes.

Also it might be worth looking at this book, you may have already heard of it / read it as it's quite well known but Beck explains the benefits / problems of Paired programming in it.

Extreme Programming Explained: Embrace Change

Hope that helps :-)

Answer 3

Martin Fowler and Neal Ford briefly cover the topic pretty well in this video on agile development:

http://universite-du-si.com/fr/conferences/6/sessions/909

I think my favorite point about pair programming in the video was that it allows each developer to use different sides of the brain (since people can generally use only one side at a time). The one at the keyboard is using the logical/technical side to try to solve the problem and make it work, the other is using the creative/contemplative side to try to envision/build a solution to the problem. Working together, what you end up with is "one complete brain" instead of a programmer who's either lost in the technical minutia or lost in the clouds of idealism.

Answer 4

IMHO in Pair Programming

• Quality is improved.
• But Potential Productivity is lost (although this ignores the 'peer pressure' benefit that pair programming could have)

Generally, we do most development using a Hybrid model

When tackling novel situations (e.g. new concepts, new technologies or difficult business domains), pair programming definitely works well. The second dev might still have a pc nearby though, to do some google fu (related to the task at hand) now and then. Data Modelling, key algorithms, workflow or business process modelling.

However, for bulk, grunt work with little intellectual requirement or highly visual work (e.g. Forms or Pages) where QA / UAT will pick up defects quickly, devs working by themselves can work just fine.

It must be said that have a senior group of devs (all 5 years +), and they are all self motivated and do work as productively as possible. This might not be true of more junior developers.

HTH

Answer 5

First off, if you're still using SourceSafe, you probably have a bigger problem with your development cycle than pair programming can solve. You're most likely not doing regular or nightly builds. You can't branch effectively. You can't go into the past and effectively retrieve changes and roll back work. This is all huge. It's like complaining about how rough your car's engine is running when you don't have any brakes.

Also, if your CIO wants to present a case, why isn't (s)he laying it out? Is it "Hey, user279521, I've heard of this thing called pair programming. See why we should do this so I can tell people we need to do it!?" If this is the case, once again, you seem to have bigger problems than this question.

That being said, pair prorgramming is not about the modification cycle. Here are my pros and cons:

Pros:

• It's a type of instant code review. Your code has been vetted by two separate programmers once it's written.
• Two people are fully up to speed on the code, providing support redundancy
• Two people can often motivate each other consistently and increase the speed of development
• If one programmer is less experienced he or she can learn from the other in real time.

Cons:

• For simple, non-challenging long-term tasks, it's often waste of time because some tasks really don't need two people.
• Two people now have to be uninterrupted in order to proceed. In dynamic environments, this can be a challenge.
• If one programmer is sufficiently junior to the other, the amount of deference that the junior programmer gives to the senior programmer limits the effectiveness of that user's input.
• If you have a personality class or a religious war in your team, pair programming can amplify it.

My advice: Pair programming is great for when you really have to figure out an implementation. Two people reviewing, bouncing ideas and caveats off one another can be a great thing. I personally think pair programming is best adopted by having an environment where programmers can pair up when the task demands it in a ergonomically accomodating, separate space where they can concentrate. It's not enough to jam two people into a one-person cube.

Answer 6

Everybody does paircoding. Many people even do n-tuple-coding.
Every line of code written requires maintenance, i.e. review and probably changing, debugging, fixing, rewriting, refactoring. Programming actually consists of maintenance.

So on any piece of code, there are several people working. It might be the same person, just at different moments in time (which basically counts a different person, that often has little or any idea about how the code, it is to maintain, works. at all).
Now the choice you are given is, to either live with the fact, that you have n people, who, due to fundamental laws of physics, CANNOT communicate (unless time travel is invented :P), work on a piece of code. Or you can simply have 2 people, who can communicate, work on it.

Good software is made of 90% thought and 10% code (for one, because code is bad). Pair coding forces people to think and to propose/defend solutions. The code is reviewed as it is written and not 2 years later, just because strange crashes occur "out of nowhere". The code is short and concise, because solutions generally grow towards simplicity, when you invest thinking instead of doing. Of course even pair programming doesn't produce perfect code, but it does produce code, that is orders of magnitude better in probably in any way you may want to measure that. In the long run, it is even less time consuming.

And one great plus of pair coding is, redundancy. For any piece of code, you have two developers, who know it. If one leaves the team, you're not instantly screwed.

Many programmers don't like the idea of pair coding. Mostly, because they are lazy or have other personal issues. The types of people, who will start religious wars about indentation or naming conventions, who can go on arguing about pointless crap all day long, and will provide you with the possibly most stupid arguments you ever heard, to proove why some practices are unneccessary, when they only don't like or understand them.

Except for the few real talents and the even fewer actual geniuses, who really can write great code locked up alone in a cellar, pair coding is the way to go for programmers. It also embeds aspects such as mentoring and competition (and contact with other human beings :D) directly into programming.

greetz
back2dos