"Coming together is a beginning. Keeping together is progress. Working together is success." - Henry Ford
Paired programming as defined by Wikipedia (sometimes referred to as peer programming) "is an agile software development technique in which two programmers work as a pair together on one workstation. One, the driver, writes code while the other, the observer, pointer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently."
It is touted for the benefits of teamwork, the clean code that it produces, and the skills that it refines. It also helps to ensure that all code is well-conceived from the start. It's important to note that it's embraced by some organizations but not others when it becomes a battle of egos and audits. Before you make a decision on how you should implement pair programming for your team, you'll want to explore some of the different aspects of pair programming that may or may not be right for your team.
When you are in a pair programming situation, you work together. This means that when a project is underway the developers work closely together. If one is not there, the project can't continue. This is a very important consideration. Managers and trainers must have a complete understanding of their team dynamic before placing developers in this situation. Spending that much time with one person can be very trying. If you don't think that your developers have the right personality or dynamic - you may want to reconsider this option.
The purpose of pair programming is to share ideas and analyze the best way to write code. The idea is to have another pair of eyes involved in the process. The code will be cleaner and the UX and application will only stand to benefit. Problems arise when egos or old ideas get in the way of the overreaching goal. If you want to implement pair programming within your organization, you need to be very clear. The goal is not for one programmer to outshine or control the other, but to produce the best possible result for the company.
There are dozens of articles that talk about the good, the bad and the ugly surrounding pair programming. A perfect example is this personal blog that we found from a developer who didn't have a good experience. With anything that's done blindly and without exception there are downsides. But pair programming doesn't have to be a solution that's implemented throughout your entire IT department. You can experiment. Ask for volunteers. Start with a team who you know is eager to try it.
You know as well as anyone that great developers are hard to find. Don't be a cautionary tale. Get feedback from your team throughout the process if you're experimenting with pair programing and make sure to make changes throughout the process. If you don't, you risk losing team members.
Remember that every organization and department is completely different. What works for one may not necessarily work for others. While pair programing has gotten a bad rap mostly from vocal developers who had a bad experience, it truly can be a very valuable way to encourage teamwork and produce better programs for your organization. Keep these considerations in mind before you give it a try and you'll set yourself up for the best chance of success.