There is a lot of debate inside the software community as to the plusses and minuses of certain development methods. Some people like the redundancy and quality of Pair Programming (or Extreme Programming), while others prefer the rapid deployment and quick feedback associates with Rapid Application Development. There are many different methods of producing software and the decision on which technique to use to solve an individual problem is a complicated one.

Rapid Application Development

Rapid Application Development (RAD) is a development technique which aims to produce a working piece of software between 60 and 90 days. It is primarily used by Service organizations who are developing software for a specific client to use. By sacrificing reliability, scalability, and code quality a client gains rapid deployment and reduced cost of development which may be vital to their project.

Walter Maner's take on RAD

Extreme Programming

Extreme Programming (XP), while not specifically aims at producing high quality code to meet shifting expectations. Unlike RAD it does not aim to release an entire product in a 2-3 months, but instead aims to have many small releases over a longer timeframe. It stresses writing tests before writing the code to guarantee that the code, when released, will not have the same bugs cropping up over and over again, this also allows programmers to write code to the tests thereby improving efficiency as the goals are already understood. Pair programming which not only allows multiple people to review the same code, but also increases knowledge transfer and prevents one person from being the only one who "knows" a section of the system. Constant refactoring prevents code from becoming unreadable and unmaintainable, it also prevents the codebase from swelling with unneccessary functionality and shoddy code.

XP is not without it's problems. It's elimination of formal written requirements leaves it vulnerable to constant changes. The redundancy of pair programming can sometimes slow the development process. The lack of detailed requirements and up front planning means that the system can have an overall shoddy design. Code refactoring is fine and good, but try fixing problems which exist on the fundamental design level.

ExtremeProgramming.org describes the process in detail
SoftwareReality.com explanation of the problems associated with Extreme Programming

Rational Unified Process

The Rational Unified Process (RUP) differs from XP in several major ways. It is less developer focused, meaning there is more up front planning, system design, requirements gathering, basically more process before developers start working and more bureaucracy. It also eliminates some of the resource inefficiency as it does not have the Pair Programming element, nor does it have the constant rotation of positions, but has its own inefficiency in its use of bureacracy. The use of User Cases (instead of User Stories) allows a tight definition of situations the software must deal with, this is compared to the User Story of XP which is more general. While the cases lead to tight requirements, they may have too narrow a focus and miss situations that the software will encounter.

Rational Systems whitepaper on Rational Unified Process