XP is a lightweight discipline of software development based on principles of simplicity, communication, feedback and courage. XP is designed for use with small teams who need to develop software quickly in an environment of rapidly changing requirements.
Of the lightweight methodologies that have recently emerged (for example, Cockburn’s Crystal Family, Higsmith’s Adaptive Software Development, SCRUM, Coad’s Feature Driven Development, DSDM and others) Extreme Programming (XP) stands out as the most popular. About a year ago, most of the postings to Usenet newsgroup comp.software-eng (discussing Software Engineering subjects) were somehow related to XP.
One could argue that Rational Unified Process (RUP) is not less popular than XP, but RUP is not a process – it is a process framework, upon which other processes (including XP) can be built, as shown by Robert Martin’s “dX process”.
XP was developed by Kent Beck at “DaimlerChrysler” in 1996, which wrote the original book on the subject, “Extreme Programming Explained”.
Ultimately, any team's software development methodology needs to be customized to the team and their circumstances. No methodology is just a collection of rules to be performed in rote fashion, and XP - in spite of its famous rules - is no exception.
When a team is newly adopting XP, it is recommended that they begin with the practices described here and in "Extreme Programming Installed". These practices will tend to keep the team on track while they build up a grasp of the principles that form the basis for the practices.
Here are the twelve key practices in XP, and my view and experience with them:
The Planning Process
Sometimes called the Planning Game, it requires the XP "customer" to define the business value of desired features, and programmers then provide cost estimates for those features. Using this information, the customer and the developers can then perform a cost/benefit analysis of each feature, enabling them to make intelligent decisions about which features to implement and which to defer. Using the XP planning process the “20-80 rule” (20 percent of the features provide 80 percent of the benefit) is leveraged.
I fully concur with The Planning Process approach and have successfully used and seen it used in many time-critical projects under the name of “Requirements Prioritization”.
Small Releases
Put a simple system into production early and update it frequently on a very short cycle. This allows the real business value of the product to be evaluated in a real-world environment, again leveraging the “20-80 rule”.
I think Small Releases only work for some projects, those for which a release is a lightweight activity (e.g., no lengthy training and extensive acceptance testing) and where even a small starting piece of functionality can provide business value. Integration with legacy systems using this approach may turn out to be an issue as well.
Metaphor
XP teams use a common "system of names" and a common system description that guides development and communication. This makes sure the team and the customer both internally and among each other understand what the other party means.
My experience with Metaphor is that having a common glossary for complex terms and abbreviations pays off.
Simple Design
A program built with XP should be the simplest program that meets the current requirements. There is not much building "for the future". Instead, the focus is on providing business value. Of course, it is necessary to ensure that you have a good design, and in XP that is brought about through Refactoring, discussed below.
I have my doubts about always following Simple Design fully. I think that the team insight about future directions of the software and no matter how relatively easy Refactoring is with dynamically typed languages and automated testing building with an extensible architecture can pay off. Finding the balance between Simple Design and “over-engineering” is key.
Testing
XP teams focus on validation of the software at all times. Programmers develop software by writing tests first, and only then, software that fulfills the requirements reflected in the tests. Furthermore, customers provide acceptance tests in advance of the development of the system – which enables both them and the developers to be certain that mandatory features are provided.
I think that the test-first philosophy is valid, though risky – whenever it is broken, the whole project can go astray.
Refactoring
XP teams improve the design of the system throughout the entire development cycle. This is done by keeping the software clean: without duplication, with high communication, simple, yet complete. Developers continually evaluate the software and recode where necessary - the goal is to keep the software system focused on the business value it was designed to provide.
In my opinion, Refactoring is the part that separates XP from hacking and “code-and-fix” approach.
It depends heavily on Testing and on using a dynamically typed language, nevertheless it still can be very hard on large projects – though better than leaving the code in mess.
Pair Programming
XP programmers write all production code in pairs, two programmers working together at one machine. XP supporters state that pair programming has been shown by experiments to produce better software at similar or lower cost than programmers working alone have.
My view is that in some circumstances it helps (long lists of defects to fix, architecturally challenging code portions), while in others it is unnecessary.
Either way, personal synergy and a healthy atmosphere are crucial. The partners should be willing to make each other a better programmer – something the usual corporate environment with a shared pool of budgeting and periodical competitive performance reviews does not facilitate.
Collective Ownership
All code belongs to all programmers. This lets the team go at full speed, because when something needs changing, it can be changed immediately.
I am afraid this will not work well for large projects, where it is difficult for any one particular programmer to grasp all the code, and even less for all programmers to do that.
Continuous Integration
Instead or in addition to creating stable builds on a published schedule, XP teams integrate and build the software system several times per day. This keeps all the programmers on the same page, and enables very rapid progress implementing the new software features. Perhaps surprisingly, integrating more frequently tends to eliminate integration problems that plague teams who integrate less often.
I have had good experience with the “nightly build” approach where at the end of the business day everybody checks in code into the versioning system and an automated process builds it after midnight.
I have doubts about building more often, since broken builds tend to happen often when in middle of development.
40-hour Week
Tired programmers make more mistakes. Since tired programmers often write lower-quality code, XP teams do not work excessive overtime, keeping themselves fresh, healthy, and effective – producing higher-quality code in less time.
I concur, but getting senior management acceptance on this is not always that easy for some projects.
On-site Customer
An XP project is steered by a dedicated individual who is empowered to determine requirements, set priorities, and answer questions as the programmers have them. This intense, face-to-face customer interaction should reduce the amount of hard-copy documentation and the high cost associated with its creation and maintenance.
My only concern with this approach is that the representatives who are entitled to have final authority over the product usually do not have that much time to spend on it.
Nevertheless, having close communication with the customer is crucial.
Coding Standard
For a team to work effectively in pairs, and to share ownership of all the code, all the programmers need to write and document the code in the same way, with rules that make sure the code communicates clearly, even if developed by different coding teams.
I think code standards should be enforced both by code reviews and by automated tools (e.g., running a formatting translator prior to check-in into the versioning system).
XP is a lot like a jig saw puzzle. There are many small pieces. Individually the pieces make no sense, but when combined together a complete picture can be seen.
Though following the twelve practices is recommended, following the four values is what XP focuses on:
- Communication: XP programmers communicate with their customers and fellow programmers.
- Simplicity: They keep their design simple and clean.
- Feedback: They get feedback by testing their software starting on day one. They deliver the system to the customers as early as possible and implement changes as suggested.
- Courage: With this foundation XP programmers are able to courageously respond to changing requirements and technology.
Some of this may actually be (c) by Kent Beck, Ron Jeffries & Co., as it is their invention.
Please msg me if you see anything I could correct or clarify - and I'm more than willing to simply discuss this subject as well.