Proponents of Extreme Programming and agile methodologies in general regard ongoing changes to requirements as a natural, inescapable and desirable aspect of software development projects; they believe that adaptability to changing requirements at any point during the project life is a more realistic and better approach than attempting to define all requirements at the beginning of a project and then expending effort to control changes to the requirements.
However, XP has been noted for several potential drawbacks, as compared to more document-based methodologies, including problems with unstable requirements, no documented compromises of user conflicts, and lack of an overall design spec or document (see below: Controversial aspects).
Although Extreme Programming itself is relatively new, many of its practices have been around for some time; the methodology, after all, takes "best practices" to extreme levels. For example, the "practice of test-first development, planning and writing tests before each micro-increment" was used as early as NASA's Project Mercury, in the early 1960s . Refactoring, modularity, bottom-up and incremental design were described by Leo Brodie in his book published in 1984.
The Chrysler Comprehensive Compensation project was started in order to determine the best way to use object technologies, using the payroll systems at Chrysler as the object of research, with Smalltalk as the language and GemStone as the data access layer. They brought in Kent Beck, a prominent Smalltalk practitioner, to do performance tuning on the system, but his role expanded as he noted several issues they were having with their development process. He took this opportunity to propose and implement some changes in their practices based on his work with his frequent collaborator, Ward Cunningham.
Beck invited Ron Jeffries to the project to help develop and refine these methods. Jeffries thereafter acted as a coach to instill the practices as habits in the C3 team.
Information about the principles and practices behind XP was disseminated to the wider world through discussions on the original Wiki, Cunningham's WikiWikiWeb. Various contributors discussed and expanded upon the ideas, and some spin-off methodologies resulted (see agile software development). Also, XP concepts have been explained, for several years, using a hyper-text system map on the XP website at "www.extremeprogramming.org" circa 1999 (website XPorg).
Beck edited a series of books on XP, beginning with his own Extreme Programming Explained (1999, ISBN 0-201-61641-6), spreading his ideas to a much larger, yet very receptive, audience. Authors in the series went through various aspects attending XP and its practices, even a book critical of the practices.
The high discipline required by the original practices often went by the wayside, causing some of these practices that were thought too rigid to be deprecated or left undone on individual sites. Agile development practices have not stood still, and XP is still evolving, assimilating more lessons from experiences in the field. In the second edition of Extreme Programming Explained, Beck added more values and practices and differentiated between primary and corollary practices.
The main aim of XP is to reduce the cost of change. In traditional system development methods (such as SSADM) the requirements for the system are determined at the beginning of the development project and often fixed from that point on. This means that the cost of changing the requirements at a later stage (a common feature of software engineering projects) will be high.
XP sets out to reduce the cost of change by introducing basic values, principles and practices. By applying XP, a system development project should be more flexible with respect to changes.
Feedback is closely related to communication and simplicity. Flaws in the system are easily communicated by writing a unit test that proves a certain piece of code will break. The direct feedback from the system tells programmers to recode this part. A customer is able to test the system periodically according to the functional requirements, known as user stories. To quote Kent Beck, "Optimism is an occupational hazard of programming, feedback is the treatment."
Adopting four earlier values led to respect gained from others in team. Nobody on the team should feel unappreciated or ignored. This ensures high level of motivation and encourages loyalty toward the team, and the goal of the project. This value is very dependent upon the other values, and is very much oriented toward people in a team.
The first version of XP rules was proposed by Ken Auer in XP/Agile Universe 2003. In short, he said: XP's values make it agile. XP's practices do not define XP; XP is defined by its rules. Because defining XP by the practices has at least two problems:
He finally concluded that we should not define XP merely by its values or its practices. We should define XP by its rules. Ken Auer in his version of XP Rules defined two categories of rules in Rules of Engagement which dictate the environment in which software development can take place effectively. They then discuss the Rules of Play which define the minute-by-minute activities and rules within the framework of the Rules of Engagement.
- Some practices are fuzzy in definition.
- It's commonly understood we can be doing XP without doing all of the practices.
1. The Rules of Play are what make XP unique. 2. Following the Rules of Play is Extreme Programming. 3. Following the Rules of Play and the Rules of Engagement is Extreme Software Development.
After Ken Auer, in APSO workshop at ICSE 2008 Conference, Mehdi Mirakhorli proposed the new version of XP Rules, he had provided some changes in the first version of XP Rules. Because he believed that the rules must satisfy the essence of agility and XP. When you choose rules for defining XP, you should be independent of any practices as much as possible. With regard to Ken’s results and according to his experiences he propose a more precise and comprehensive definition for the rules of engagement and play.
- Honest communication leading to continuous learning and an emphasis on person-to-person interaction, rather than documentation.
- Minimal degrees of separation from what is needed by the team to make progress and the people/resources that can meet those needs.
- Alignment of authority and responsibility.
Rules of play that make XP unique are defined below these rules are based on XP’s values (Communication, Simplicity, Feedback, Courage)
Extreme Programming sees feedback as most useful if it is done rapidly and expresses that the time between an action and its feedback is critical to learning and making changes. Unlike traditional system development methods, contact with the customer occurs in more frequent iterations. The customer has clear insight into the system that is being developed. He or she can give feedback and steer the development as needed.
Unit tests also contribute to the rapid feedback principle. When writing code, the unit test provides direct feedback as to how the system reacts to the changes one has made. If, for instance, the changes affect a part of the system that is not in the scope of the programmer who made them, that programmer will not notice the flaw. There is a large chance that this bug will appear when the system is in production.
Assuming simplicity is about treating every problem as if its solution were "extremely simple". Traditional system development methods say to plan for the future and to code for reusability. Extreme programming rejects these ideas.
The advocates of Extreme Programming say that making big changes all at once does not work. Extreme Programming applies incremental changes: for example, a system might have small releases every three weeks. By making many little steps the customer has more control over the development process and the system that is being developed.
The principle of embracing change is about not working against changes but embracing them. For instance, if at one of the iterative meetings it appears that the customer's requirements have changed dramatically, programmers are to embrace this and plan the new requirements for the next iteration.
Coding can be drawing diagrams that will generate code, scripting a web-based system or coding a program that needs to be compiled.
Coding can also be used to figure out the most suitable solution. For instance, XP would advocate that faced with several alternatives for a programming problem, one should simply code all solutions and determine with automated tests (discussed in the next section) which solution is most suitable.
Coding can also help to communicate thoughts about programming problems. A programmer dealing with a complex programming problem and finding it hard to explain the solution to fellow programmers might code it and use the code to demonstrate what he or she means. Code, say the exponents of this position, is always clear and concise and cannot be interpreted in more than one way. Other programmers can give feedback on this code by also coding their thoughts.
A "testathon" is an event when programmers meet to do collaborative test writing, a kind of brainstorming relative to software testing.
Programmers have to listen "in the large": they have to listen to what the customer needs. Also, they have to try to understand the business problem, and to give the customer feedback about his or her problem, to improve the customer's own understanding of his or her problem.
Communication between the customer and programmer is further addressed in The Planning Game.
One can avoid this by creating a design structure that organizes the logic in the system. Good design will avoid lots of dependencies within a system; this means that changing one part of the system will not affect other parts of the system.
Extreme Programming has been described as having 12 practices, grouped into four areas:
Fine scale feedback
Unstable Requirements: Proponents of Extreme Programming claim that by having the on-site customer request changes informally, the process becomes flexible, and saves the cost of formal overhead. Critics of XP claim this can lead to costly rework and project scope creep beyond what was previously agreed or funded.
User Conflicts: Change control boards are a sign that there are potential conflicts in project objectives and constraints between multiple users. XP's expedited methodology is somewhat dependent on programmers being able to assume a unified client viewpoint so the programmer can concentrate on coding rather than documentation of compromise objectives and constraints. This also applies when multiple programming organizations are involved, particularly organizations which compete for shares of projects.
Other Aspects: Other potentially controversial aspects of Extreme Programming include:
Dependence upon all other aspects of XP: "XP is like a ring of poisonous snakes, daisy-chained together. All it takes is for one of them to wriggle loose, and you've got a very angry, poisonous snake heading your way."
Scalability: Historically, XP only works on teams of twelve or fewer people. One way to circumvent this limitation is to break up the project into smaller pieces and the team into smaller groups. It has been claimed that XP has been used successfully on teams of over a hundred developers. ThoughtWorks has claimed reasonable success on distributed XP projects with up to sixty people.
Controversy in Book: In 2003, Matt Stephens and Doug Rosenberg published a book under Apress called Extreme Programming Refactored: The Case Against XP which questioned the value of the XP process and suggested ways in which it could be improved. This triggered a lengthy debate in articles, internet newsgroups, and web-site chat areas. The core argument of the book is that XP's practices are interdependent but that few practical organizations are willing/able to adopt all the practices; therefore the entire process fails. The book also makes other criticisms and it draws a likeness of XP's "collective ownership" model to socialism in a negative manner.
XP Evolution: Certain aspects of XP have changed since the book Extreme Programming Refactored (2003) was published; in particular, XP now accommodates modifications to the practices as long as the required objectives are still met. XP also uses increasingly generic terms for processes. Some argue that these changes invalidate previous criticisms; others claim that this is simply watering the process down. In 2004 Industrial Extreme Programming (IXP) was introduced as an evolution of XP. It brings ability to work in big and distributed teams. It now has 23 practices and flexible changeable values. As it is a new member of en:Category:Agile software development family, there is not enough data to prove its usability, however it claims to be an answer to XP's imperfections.
XP Customization: Although software projects can benefit from XP practices, not all projects can directly adopt it. Characteristics of some projects make it difficult to use XP thoroughly; therefore, the need for tailoring XP to the local conditions, contexts and the size of projects is inevitable.
RDP Practice is a technique for tailoring Extreme Programming. This practice was initially proposed as a long research paper in a workshop organized by Philippe Kruchten and Steve Adolph(See APSO workshop at ICSE 2008) and yet it is the only proposed and applicable method for customizing XP. The valuable concepts behind RDP practice, in a short time provided the rationale for applicability of it in industries. RDP Practice tries to customize XP by relying on XP Rules.
Hybrid/Unified Methodologies: Other authors have tried to reconcile XP with the older methods in order to form a unified methodology. Some of these XP sought to replace, such as the waterfall method; example: Project Lifecycles: Waterfall, Rapid Application Development, and All That
JPMorgan Chase & Co. tried combining XP with the computer programming methodologies of Capability Maturity Model Integration (CMMI), and Six Sigma. They found that the three systems reinforced each other well, leading to better development, and did not mutually contradict, see Extreme Programming (XP) Six Sigma CMMI
Projects suited for more conventional methodologies are those that:
Project Managers must weigh project aspects against available methodologies to make an appropriate selection. However, some XP concepts could be applied outside, such as using Pair Programming to expedite related technical changes to the documentation set of a large project.
ThoughtWorks' experiences with implementing XP in large distributed projects can be found at Using an Agile Software Process with Offshore Development
Nuanced opinion or Anti-XP