The first time I heard the phrase Extreme Programming, I had visions of all-night coding sessions with cans of Jolt cola and Mountain Dew strewn about. Far from it, Extreme Programming (XP), the latest craze in software construction methodologies, actually advocates a 40-hour workweek. The term extreme comes from XPs radical departure from the complex, time-consuming techniques of well-known and long-accepted methodologies.
Consider this quote from one of Kent Becks XP converts: XP matches observations of programmers in the wild. (Beck is the author of Xtreme Programming XplainedEmbrace Change.) So yes, XP is radical, and the best way that I can describe XP is to list its practices and then summarize XPs project cycle.
XP Practices
PlanningDetermine the scope of the next release by combining business priorities with technical estimates made by coders.
Small releasesUse iterative development where each release is delivered in one to three weeks.
MetaphorStart with a simple, shared story of how the system is to work.
Simple designFollow the doctrine of, as Beck says, extracomplexity removed as soon as it is discovered, but strive not to use complex designs in the first place.
TestingHave coders write unit tests for all methods and customers write functional tests for the application.
RefactoringContinually strive to remove duplicate code and find ways to simplify code while adding flexibilityi.e., do over.
Pair-programmingAll production code is done by two coders sharing one workstation.
Collective ownershipAllow anyone to be able to change any code anywhere in the system at any time.
Continuous integrationBuild and completely test the system several times a day.
40-hour weekIt is an absolute rule that you cant go over 40 hours two weeks in a row.
On-site customerHave a user expert on the team full time to develop functional tests and provide continuous feedback.
Coding standardsBecause everyone owns all the code of the system, it must all look the same throughout the system.
XP Project Cycle
An XP project seeks to deliver the system every one to three weeks. The idea is to drop grandiose design schemes and replace them with a simple story of the system that everyone understands and agrees on. The project starts with the most basic of the requirements for thesystems. The design is done using the simple strategy of 3 x 5 Class-Responsibility- Collaborator (CRC) cards. (To get a better idea how CRC cards are used to design object- oriented systems, read c2.com/doc/oopsla89/paper.html.) After the hyper design phase is done, coders select 3 x 5 cards, estimate the amount of time to deliver, select a partner, and begin coding. One coder is the driver, and the other is the planner. The driver fleshes out the code for the task, and the planner looks for coding errors while planning how to test the code and improve the overall design.
Pair Programming
This pair programming goes against common coding practices, and my first thought about it was that it would result in less code. But studies have shown that pair programming always results in cleaner and more concise code. Quality code means fewer bugs and, after coders become comfortable with pair programming, output catches up with cave coding anyway.
One of the immediate benefits of pair programming is continuous code reviews. Ive always been an advocate of code reviews, but, because they burn up lots of time and resources, code reviews are often skipped. With XP, code reviews go on constantly (because you always work in pairs), and therefore are extremely effective.
Testing and Collective Ownership
Testing is the name of the game with XP. Coders become test infected because they wont add a feature unless they can test that feature. Unit tests provide instant gratification while establishing coder confidence. The XP team customer is responsible for adding functional tests as features are added to the systems.
As a coding pair completes a task, it integrates its code to the system. At this point, the coding pair not only tests its new code but also runs the automated tests for the entire system. If any test fails, the coding pair is to fix any code that failseven if it didnt code it. Thats called collective ownershipall the coders are responsible for all the code in the system.
Iterative Development
After a one- to three-week phase is complete, the system is delivered to the customer. Feedback is instantaneous, and a subsequent project cycle begins. Features are added and designs are changed. In other words, the scope of the project evolves after each iteration.
Is XP for You?
Should you be using XP? First, remember that XP is a radical new methodology. Your companys coders and management must be willing to try a completely new way of designing, coding, and delivering systems. XPs use of numerous releases and continual evolution of a project may not work in your business environment. Note, too, that XP works best for small projects, ones with two to 10 coders. And last, XP is dependant on modular programming, if not object-oriented programming. The continual integration and system testing of XP require a programming language that supports fast builds and automated unit tests. XP success stories were built using C++, Java, and Smalltalk.
LATEST COMMENTS
MC Press Online