Over the past ten years or so Extreme Programming has been slowly gaining acceptance as a potentially beneficial software development technique both in the commercial and academic worlds. Here we review the existing literature to attempt to gain insight into the practice of pair programming across both educational and commercial contexts. We begin by considering the pair programming team and the environment in which pairing takes place. We then review a number of studies aimed at measuring the costs and benefits of programming in a pair, particularly in terms of the quality of the software produced. Finally we discuss the potential cognitive benefits of pair programming and consider when and where its use might be most appropriate.

Pair programming is is hard. Here are some tips to make it easier.

Pair programming is touted as a way of building a better system: two heads are better than one, they say, and thus two heads will usually produce a higher-quality system.

Saros is a plug-in for the Eclipse IDE that enables two or more distributed programmers to develop projects in real-time over the Internet and share each other’s changes. It allows users to communicate in a variety of ways as they collaborate and also to remain constantly aware of their partners' activities through various sorts of awareness information.

This paper describes techniques that can be used to reduce the execution time and maintenance cost of the automated regression test suites that are used to drive development in eXtreme Programming (XP). They are important because developers are more likely to write and run test, thus getting valuable feedback, if testing is as painless as possible. Test execution time can be reduced by using an in-memory database to eliminate the latency introduced by accessing a disk-based database and/or file system. This paper also describes how the effort of test development can be reduced through the use of a framework that simplifies setup and teardown of text fixtures.

People who aren't familiar with XP are bothered by the concept of just-in-time (JIT) design -- designing and implementing what you know you need right now and not worrying about future design issues until absolutely necessary. While this approach might seem unwise or even reckless, XP advocate Roy Miller wraps up his series by showing you how safe and easy JIT design is -- and how it just might revolutionize the way you write code.

Test-driven programming is one aspect of XP that baffles programmers. Many of us make incorrect assumptions about what it means and how to do it. This month, XP coach and Java developer Roy Miller talks about what test-driven programming is about, why it can revolutionize your productivity and quality as a programmer, and the mechanics of writing tests. For the last fifty years, testing has been viewed as something that gets done toward the end of a project. Sure, there may be integration testing while the project is going on, and testing doesn't usually start after all the coding is done, but it's usually in a later phase. However, proponents of XP suggest that this model is completely backwards. As a programmer, you should write tests before you write code, then write just enough code to get the tests to pass. Doing that will help you keep your system as simple as possible.

Certain XP practices make project managers scoff and programmers wince. Pair programming (or pairing) is one of them. Based on feedback from some of XP's critics, pair programming gets the award for "practice most likely to offend" -- that is, if you had to pick just one. This month, XP coach Roy Miller talks about this radical way to write code, including the misconceptions surrounding pairing, why so many software developers hate it, and why it's so important to your project's success.

Project money has to come from somewhere, and most likely the person who owns the budget knows very little about XP or agile methods. If that person is familiar with these programming concepts, I suspect he thinks the idea is nuts or just too risky. Asking for money from a skeptical source can be risky business. One of the best ways for a manager to do so credibly is to make sure he's speaking the sponsor's language.

This article explores why customers (the business decision-makers) seem to have the most difficult time with this shift. Until they change the way they think about and participate in software projects, the end result will never be a satisfactory one. XP requires a profound shift in the way business people think. Over the past 30 years, software development methodologies have conditioned non-technical people in business to think and behave in certain ways. Unfortunately, traditional methodologies are wrong because they doesn't consistently produce the results these people want: software that meets their needs at the end of a project, software that has a long useful life, and software that gets delivered often.