Figure 1. The evolution of the Waterfall Model (a) and its long development cycles (analysis, design, implementation, test) to the shorter, iterative devel-opment cycles within, for example, the Spiral Model (b) to Extreme Programming’s (c) blending of all these activities, a little at a time, throughout theentire software development process.
0018-9162/99/$10.00 © 1999 IEEE70 Computer
In the beginning was the waterfall (Figure 1a). Wewould get the users to tell us once and for allexactly what they wanted. We would design thesystem that would deliver those features. Wewould code it. We would test to make sure the
features were delivered. All would be well.All was not well. The users didn’t tell us once and
for all exactly what they wanted. They didn’t know.They contradicted themselves. They changed theirminds. And the users weren’t the only problem. Weprogrammers could think we were making greatprogress only to discover three-fourths of the waythrough that we were one-third of the way through.
If long development cycles were bad because theycouldn’t adapt to changes, perhaps what we neededwas to make shorter development cycles. As Figure 1b
shows, the waterfall begat iterations.The waterfall model didn’t just appear. It was a
rational reaction to the shocking measurement thatthe cost of changing a piece of software rose dramat-ically over time. If that’s true, then you want to makethe biggest, most far-reaching decisions as early in thelife cycle as possible to avoid paying big bucks forthem.
The academic software engineering communitytook the high cost of changing software as a challenge,creating technologies like relational databases, mod-ular programming, and information hiding. What ifall that hard work paid off? What if we got good atreducing the costs of ongoing changes? What if wedidn’t have to settle for taking a cleaver to the water-fall? What if we could throw it in a blender?
Extreme Programming turns the conventional software process sideways.Rather than planning, analyzing, and designing for the far-flung future, XPprogrammers do all of these activities—a little at a time—throughout development.
Cover Feature
Embracing Change withExtremeProgramming
Kent BeckFirst ClassSoftware
Cove
r Fea
ture
Analysis
Design
Implementation
Test
Time
Scope
IterativeWaterfall XP
(c)(b)(a)
October 1999 71
We might get a picture like the one shown in Figure1c. It’s called Extreme Programming.
ANATOMY OF XPXP turns the conventional software process side-
ways. Rather than planning, analyzing, and design-ing for the far-flung future, XP exploits the reductionin the cost of changing software to do all of theseactivities a little at a time, throughout software devel-opment. (The “XP Practices” sidebar will give you aquick grasp of the practices and philosophy underly-ing XP. These practices are designed to work together,and trying to examine any one soon leads you to therest. The “Roots of XP” sidebar on page 73 traces thehistorical antecedents of these practices.)
XP development cycleFigure 2 shows XP at timescales ranging from years
to days. The customer picks the next release by choos-ing the most valuable features (called stories in XP)from among all the possible stories, as informed bythe costs of the stories and the measured speed of theteam in implementing stories.
The customer picks the next iteration’s stories bychoosing the most valuable stories remaining in therelease, again informed by the costs of the stories andthe team’s speed. The programmers turn the storiesinto smaller-grained tasks, which they individually
XP Practices
Here is a quick summary of each of themajor practices in XP.
Planning game. Customers decide thescope and timing of releases basedon estimates provided by program-mers. Programmers implement onlythe functionality demanded by thestories in this iteration.
Small releases. The system is put intoproduction in a few months, beforesolving the whole problem. Newreleases are made often—anywherefrom daily to monthly.
Metaphor. The shape of the system isdefined by a metaphor or set ofmetaphors shared between the cus-tomer and programmers.
Simple design. At every moment, thedesign runs all the tests, communi-cates everything the programmerswant to communicate, contains no
duplicate code, and has the fewestpossible classes and methods. Thisrule can be summarized as, “Sayeverything once and only once.”
Tests. Programmers write unit testsminute by minute. These tests are col-lected and they must all run correctly.Customers write functional tests forthe stories in an iteration. These testsshould also all run, although practi-cally speaking, sometimes a businessdecision must be made comparing thecost of shipping a known defect andthe cost of delay.
Refactoring. The design of the systemis evolved through transformationsof the existing design that keep allthe tests running.
Pair programming. All productioncode is written by two people at onescreen/keyboard/mouse.
Continuous integration. New code isintegrated with the current systemafter no more than a few hours.
When integrating, the system is builtfrom scratch and all tests must passor the changes are discarded.
Collective ownership. Every program-mer improves any code anywhere inthe system at any time if they see theopportunity.
On-site customer. A customer sits withthe team full-time.
40-hour weeks. No one can work asecond consecutive week of over-time. Even isolated overtime usedtoo frequently is a sign of deeperproblems that must be addressed.
Open workspace. The team works in alarge room with small cubicles aroundthe periphery. Pair programmers workon computers set up in the center.
Just rules. By being part of an Extremeteam, you sign up to follow the rules.But they’re just the rules. The teamcan change the rules at any time aslong as they agree on how they willassess the effects of the change.
accept responsibility for.Then the programmer turns a task into a set of test
cases that will demonstrate that the task is finished.Working with a partner, the programmer makes thetest cases run, evolving the design in the meantime tomaintain the simplest possible design for the systemas a whole.
StoriesXP considers the period before a system first goes
into production to be a dangerous anomaly in the lifeof the project and to be gotten over as quickly as pos-sible. However, every project has to start somewhere.
The first decisions to make about the project arewhat it could do and what it should do first. These deci-sions are typically the province of analysis, hence thethin blue analysis rectangle at the top of Figure 1c. Youcan’t program until you know what you’re program-ming.
You put the overall analysis together in terms ofstories, which you can think of as the amount of a usecase that will fit on an index card. Each story must bebusiness-oriented, testable, and estimable.
A month is a good long time to come up with thestories for a 10 person-year project. It’s true that itisn’t enough to explore all of the possible issues thor-oughly. But forever isn’t long enough to explore all ofthe issues thoroughly if you never implement.
72 Computer
ReleaseNotice in Figure 2 that we don’t implement all of
the stories at first. Instead, the customer chooses thesmallest set of the most valuable stories that make sensetogether. First we implement those and put them intoproduction. After that we’ll implement all the rest.
Picking the scope for a release is a little like shop-ping for groceries. You go to the store with $100 inyour pocket. You think about your priorities. You lookat the prices on the items. You decide what to buy.
In the planning game (the XP planning process), theitems are the stories. The prices are the estimates onthe stories. The budget is calculated by measuring theteam’s output in terms of estimated stories deliveredper unit time.
The customer can either load up a cart (pick a set ofstories) and have the programmers calculate the finishdate or pick a date and have the programmers calcu-late the budget, then choose stories until they add up.
IterationThe goal of each iteration is to put into production
some new stories that are tested and ready to go. Theprocess starts with a plan that sets out the stories to beimplemented and breaks out how the team willaccomplish it. While the team is implementing, thecustomer is specifying functional tests. At the end ofthe iteration, the tests should run and the team shouldbe ready for the next iteration.
Iteration planning starts by again asking the cus-tomer to pick the most valuable stories, this time out
of the stories remaining to be implemented in thisrelease. The team breaks the stories down into tasks,units of implementation that one person could imple-ment in a few days. If there are technical tasks, likeupgrading to a new version of a database, they get puton the list too.
Next, programmers sign up for the tasks they wantto be responsible for implementing. After all the tasksare spoken for, the programmer responsible for a taskestimates it, this time in ideal programming days.Everyone’s task estimates are added up, and if someprogrammers are over and some are under, the under-committed programmers take more tasks.
Over the course of the iteration, the programmersimplement their tasks. As they complete each task, theyintegrate its code and tests with the current system. Alltests must run or the code cannot be integrated.
As the customer delivers the functional tests dur-ing the iteration, they are added to the suite. At theend of the iteration, all unit tests and all functionaltests run.
TaskTo implement a task, the responsible programmer
first finds a partner because all production code is writ-ten with two people at one machine. If there is anyquestion about the scope or implementation approach,the partners will have a short (15-minute) meeting withthe customer and/or with the programmers mostknowledgeable about the code most likely to betouched during implementation.
Release
Years
Months
Weeks
Days
Iteration
Implementation
Stories
Tasks
Tests
Figure 2. XP according to various timescales. At the scale of months and years, you have the stories in this release and thenthe stories in future releases. At the scale of weeks and months, you have stories in this iteration and then the stories remain-ing in this release. At the scale of days and weeks, you have the task you are working on now and then the rest of the tasks inthe iteration. And at the scale of minutes and days, you have the test case you are working on now and then the rest of the testcases that you can imagine.
From this meeting, the partners condense the list oftest cases that need to run before the task is done. Theypick a test case from the list that they are confidentthey can implement and that will teach them some-thing about the task. They code up the test case. If thetest case already runs, they go on. Normally, though,there is work to be done.
When we have a test case and it doesn’t run, either
• we can see a clean way to make it run, in whichcase we make it run; or
• we can see an ugly way to make it run, but wecan imagine a new design in which it could bemade to run cleanly, in which case we refactorthe system to make it run cleanly; or
• we can see an ugly way to make it run, but wecan’t imagine any refactoring, in which case wemake it run the ugly way.
After the test case runs, if we see how to refactor
the system to make it even cleaner, we do so.Perhaps during the implementation of this test case
we imagine another test case that should also run. Wenote the new test case on our list and continue.Perhaps we spot a bigger refactoring that doesn’t fitinto the scope of our current test. We also note thatand continue. The goal is to remain focused so we cando a good job and at the same time not lose the ben-efits of the insights that come during intense interac-tion with code.
TestIf there is a technique at the heart of XP, it is unit
testing. As you saw above, unit testing is part ofevery programmer’s daily business. In XP, however,two twists on conventional testing strategies make testsfar more effective: Programmers write their own testsand they write these tests before they code. If pro-gramming is about learning, and learning is about get-ting lots of feedback as quickly as possible, then you
October 1999 73
Roots of XP
The individual practices in XP are notby any means new. Many people havecome to similar conclusions about thebest way to deliver software in environ-ments where requirements change vio-lently.1-3
The strict split between business andtechnical decision making in XP comesfrom the work of the architect Christo-pher Alexander, in particular his workThe Timeless Way of Building,4 where hesays that the people who occupy a struc-ture should (in conjunction with a build-ing professional) be the ones to make thehigh-impact decisions about it.
XP’s rapid evolution of a plan inresponse to business or technical changesechoes the Scrum methodology5 and WardCunningham’s Episodes pattern language.6
The emphasis on specifying and sched-uling projects from the perspective of fea-tures comes from Ivar Jacobson’s workon use cases.7
Tom Gilb is the guru of evolutionarydelivery. His recent writings on EVO8
focus on getting the software into pro-duction in a matter of weeks, then grow-ing it from there.
Barry Boehm’s Spiral Model was theinitial response to the waterfall.9 Dave
Thomas and his colleagues at ObjectTechnology International have long beenchampions of exploiting powerful tech-nology with their JIT method.10
XP’s use of metaphors comes fromGeorge Lakoff and Mark Johnson’sbooks, the latest of which is Philosophy inthe Flesh.11 It also comes from RichardCoyne, who links metaphor with soft-ware development from the perspectiveof postmodern philosophy.12
Finally, XP’s attitude toward the effectsof office space on programmers comesfrom Jim Coplien,13 Tom DeMarco, andTim Lister,14 who talk about the impor-tance of the physical environment on pro-grammers.
References1. J. Wood and D. Silver, Joint Application
Development, John Wiley & Sons, NewYork, 1995.
2. J. Martin, Rapid Application Development,Prentice Hall,Upper Saddle River, N.J.,1992.
3. J. Stapleton, Dynamic Systems Develop-ment Method, Addison Wesley Longman,Reading, Mass., 1997.
4. C. Alexander, The Timeless Way of Build-ing, Oxford University Press, New York,1979.
5. H. Takeuchi and I. Nonaka, “The NewProduct Development Game,” Harvard
Business Rev., Jan./Feb. 1986, pp. 137-146.
6. W. Cunningham, “Episodes: A PatternLanguage of Competitive Development,”Pattern Languages of Program Design 2,J. Vlissides, ed., Addison-Wesley, NewYork, 1996.
7. I. Jacobsen, Object-Oriented SoftwareEngineering, Addison-Wesley, New York,1994.
8. T. Gilb, Principles of Software Engineer-ing Management, Addison-Wesley, Wok-ingham, UK, 1988.
9. B. Boehm, “A Spiral Model of SoftwareDevelopment and Enhancement,” Com-puter, May 1988, pp. 61-72.
10. D. Thomas, “Web Time Software Devel-opment,” Software Development, Oct.1998, p. 80.
11. G. Lakoff and M. Johnson, Philosophy inthe Flesh, Basic Books, New York, 1998.
12. R. Coyne, Designing Information Tech-nology in the Postmodern Age, MITPress, Cambridge, Mass., 1995.
13. J.O. Coplien, “A Generative DevelopmentProcess Pattern Language,” The PatternsHandbook, L. Rising, ed., Cambridge Uni-versity Press, New York, 1998, pp. 243-300.
14. T. DeMarco and T. Lister, Peopleware,Dorset House, New York, 1999.
74 Computer
can learn much from tests written by someone else daysor weeks after the code. XP primarily addresses theaccepted wisdom that programmers can’t possibly testtheir own code by having you write code in pairs.
Some methodologies, like Cleanroom,1 prohibitprogrammers testing or in some cases even com-piling their own programs. The usual process has aprogrammer write some code, compile it, makesure it works, then pass it on to a testing organiza-tion. The bench testing takes the form of single-stepping through the code and watching variables,or interpreting the results of print statements, orpoking a few buttons to make sure the list itemturns green.
The XP testing strategy doesn’t ask any more workthan the usual bench testing strategies. It just changesthe form of the tests. Instead of activities that evapo-rate into the ether as soon as they are finished, yourecord the tests in a permanent form. These tests willrun automatically today, and this afternoon after weall integrate, and tomorrow, and next week, and next
year. The confidence they embody accumulates, so anXP team gains confidence in the behavior of its sys-tem over time.
As I mentioned earlier, tests also come from the cus-tomers. At the beginning of an iteration, the customersthink about what would convince them that the sto-ries for an iteration are completed. These thoughts areconverted into systemwide tests, either directly by thecustomer using a textual or graphical scripting lan-guage or by the programmers using their own testingtools. These tests, too, accumulate confidence, but inthis case they accumulate the customer’s confidencein the correct operation of the system.
WHEN SOMETHING GOES WRONGTalking about how a method works when it works
perfectly is about like describing precisely how youwill descend a monstrous patch of white water. Whatis interesting is precisely what you will do when theunexpected or undesired happens. Here are some com-mon failures and possible Extreme reactions.
Acxiom: Working toward a Common Goal
Jim Hannula, Acxiom
On top of a data warehouse, Acxiombuilt a campaign management applica-tion using Forté’s distributed OO devel-opment tool. The small developmentteam—consisting of 10 developers—builtthe application by relying on sound OOprinciples and a strong team developmentapproach.
During the final two years of the appli-cation’s three years of development, theteam—comprised of managers, businessanalysts, developers, testers, and techni-cal writers—used Extreme Programmingtechniques, which proved to be instru-mental in our success.
We know we have a good design if it’ssimple. Some of our past designs triedeven to account for future iterations ofour application. We discovered that wewere not very good at that. If we use pat-terns and communicate well, we candevelop a sound application that is flexi-ble and can still be modified in the future.
Refactoring is a major part of ourdevelopment effort. It was evident to usthat if we were afraid to change somecode because we did not know what it
did, we were not very good developers.We were letting the code control us. If wedon’t know what the code does now, webreak it and find out. It is better to imple-ment a solid piece of code than it is to leta piece of code control the application.
Unit testing was a hard piece to imple-ment because Forté did not have a ready-built testing framework. We developedour own testing framework and have beensuccessful implementing it. Recently westarted using Java as a development lan-guage and now use JUnit as a testing tool.
The key to XP is setting developer andteam expectations. We have found alldevelopers on the team must buy intoExtreme or it doesn’t work. We tellprospective developers if they do notwant to follow our development style,this is not a good team for them. One per-son not buying in to the approach willbring down the whole team. XP focuseson the team working together to come upwith new ideas to develop the system.
When we first started with XP, some ofthe developers did not want to follow it.They felt that it would hurt their devel-opment style and that they would not beas productive. What happened was thattheir pieces of the application were pro-ducing the most problem reports. Since
they were not developing in pairs, twopeople had not designed the subsystemand their skills were falling behind theother developers who were learning fromeach other. Two well-trained developersworking together and with the rest of theteam will always outperform one “intel-ligent” developer working alone.
A misconception about XP is that it sti-fles your creativity and individual growth.It’s actually quite the contrary. XP stimu-lates growth and creativity and encouragesteam members to take chances. The key isto decide the direction of the corporationand stand behind the hard decisions.
XP is not extreme to our team. It’s amethod that uses a common-sense devel-opment approach. Everyone works to-gether toward a common goal.
Team: managers, business ana- lysts, developers, testers, andtechnical writers
Application: campaign manage-ment dbase
Time: three years
October 1999 75
UnderestimationFrom time to time you will commit to more than
you can accomplish. You must reduce the occurrenceof underestimation as much as possible by getting lotsof practice estimating. If you are overcommited, youfirst try to solve the problem in the family. Have youslipped away from the practices? Are you testing, pair-ing, refactoring, and integrating as well as you can?Are you delivering more than the customer needs inplaces?
If you can’t find any way to go faster, you have toask the customer for relief. Staying committed to morework than you can confidently complete is a recipe forfrustration, slipping quality, and burnout. Don’t dothat. Re-estimate based on what you’ve learned, thenask the customer to reschedule. We can only completetwo out of three stories, so which two should we fin-ish and which one goes in the next iteration or release?Is there a story that has more critical parts and less
critical parts so we can split it and deliver the mostimportant parts now and the less important parts later?
Uncooperative customersWhat if you get a customer who just won’t play the
game? They won’t specify tests, they won’t decide onpriorities, they won’t write stories. First, by complet-ing functionality iteration after iteration, and by givingthe customer clear control over development, you aretrying to build a trust relationship with the customer.If trust begins to break down, figure out if it’s yourfault. Can you do a better job of communicating?
If you can’t solve the problem on your own, you haveto ask the customer for help. Extreme programmerssimply don’t go ahead based on their own guesses.Explain or demonstrate the consequences to the cus-tomer. If they don’t change, make your concerns morevisible. If no one cares enough to solve the problem,perhaps the project isn’t a high enough priority to go on.
DaimlerChrysler: The Best Team in the World
Chet Hendrickson, DaimlerChrysler
The C3 project began in January 1995under a fixed-priced contract that calledfor a joint team of Chrysler and contractpartner employees. Most of the develop-ment work had been completed by early1996. Our contract partners had used avery GUI-centered development method-ology, which had ignored automated test-ing. As a result, we had a payroll systemthat had a lot of very cool GUIs, calculatedmost employees’ pay incorrectly, andwould need about 100 days to generatethe monthly payroll. Most of us knew theprogram we had written would never gointo production.
We sought Kent Beck to help with per-formance tuning. He found what he hadoften found when brought in to do per-formance tuning: poorly factored code, norepeatable tests, and a management thathad lost confidence in the project. He wentto Chrysler Information Services manage-ment and told them what he had found,and that he knew how to fix it. Throw allthe existing code away! The first full XPproject was born.
We brought Kent in as head coach; hewould spend about a week per monthwith us. Ron Jeffries was brought in as
Kent’s full-time eyes and ears. The fixed-price contract was cancelled, and aboutone-half of the Chrysler developers werereassigned. Martin Fowler, who had beenadvising the Chrysler side of the project allalong and clashing with the fixed-pricecontractor, came in to help the customersdevelop user stories. From there, we fol-lowed Kent as he made up the rules of XP.A commitment schedule was developed,iterations were laid out, rules for testingwere established, and paired programmingwas tried and accepted as the standard.
At the end of 33 weeks, we had a sys-tem that was ready to begin performancetuning and parallel testing. Ready to begintuning because it was well factored andbacked up by a full battery of unit tests.And, ready to begin parallel testingbecause a suite of functional tests hadshown the customers that the requiredfunctionality was present.
That increment of C3 launched in May1997, not as soon as we had hoped. Wewere slowed by two factors. First, we haddecided to replace only the internals of thepayroll system. We left all of the externalinterfaces intact. Matching up the outputfrom our new system to the old payrollmaster ended up being a much larger taskthen we had originally estimated. Second,we decided not to launch during any payperiod with special processing require-
ments, such as W-2 processing, profit shar-ing, or general merit pay increases. Thiseffectively eliminates November throughApril.
Since the launch of the monthly system,we’ve added several new features, and wehave enhanced the system to pay thebiweekly paid population. We have beenpaying a pilot group since August 1998and will roll out the rest before the Y2Kcode freeze in November 1999.
Looking back on this long developmentexperience, I can say that when we havefallen short of keeping our promises toour management and our customers, ithas been because we have strayed fromthe principles of XP. When we have dri-ven our development with tests, when wehave written code in pairs, when we havedone the simplest thing that could possi-bly work, we have been the best softwaredevelopment team on the face of theearth.
Team: 10 programmers, 15 totalApplication: large-scale payroll system
Time: four years
TurnoverWhat if someone leaves? Won’t you be stuck with-
out documents and reviews? First, a certain amount ofturnover is good for the team and for the people on theteam. However, you’d like people to leave for positivereasons. If programmers go home at the end of everyweek seeing the concrete things they have accom-plished for the customer, they are less likely to get frus-trated and leave.
When someone leaves an XP project, it isn’t likethey can take away any secrets that only they know.Two people were watching every line go into the sys-tem. And whatever information does walk out thedoor, it can’t hurt the team too much because they canrun the tests to ensure that they haven’t broken any-thing out of ignorance.
New people on an XP team spend the first coupleof iterations just pairing with more experienced peo-ple, reading tests, and talking with the customer. Whenthey feel ready, they can accept responsibility for tasks.Over the course of the next few iterations, their per-sonal velocity will rise as they demonstrate that theycan deliver their tasks on time. After a few months,they are indistinguishable from the old salts.
Programmers that don’t work out with the teamare a problem, too. XP is an intensely social activity,and not everyone can learn it. It also requires aban-
doning old habits, which can be difficult, especiallyfor high-status programmers. In the end, though, themany forms of feedback in XP make it clear who isworking out and who isn’t. Someone who consis-tently doesn’t complete tasks, whose integrationscause problems for other people, who doesn’t refac-tor, pair, or test …. Everyone on the team knows thescore. And the team is better off without that person,no matter how skilled.
Changing requirementsThe bugaboo of most software development is just
not a problem in XP. By designing for today, an XP sys-tem is equally prepared to go any direction tomorrow.Things that are like what you’ve already done will beeasier, just by the nature of refactoring to satisfy “onceand only once,” but those are precisely the things thatare most likely to happen. However, should a radicallynew requirement arise, you won’t have to unwind (orlive with) a lot of mechanism built on speculation.
I didn’t initially realize the extent to which XP canadapt to changing requirements. The first version ofXP assigned stories to all the iterations in a release,as part of release planning. The team discovered thatthey could get better results with less planning by onlyasking the customer to pick which stories should bein the present iteration. If a new story comes up, you
76 Computer
Ford Motor: A Unique Combination of Agility and Quality
Don Wells, Ford Motor
Finance Systems at Ford Motor hasbeen developing the Vehicle Costing andProfit System (VCAPS), an analysis toolthat produces reports on production rev-enues, expenses, net income, and profit.The input is a bill of materials, fixed costsand expenses, and variable costs such aslabor hours. VCAPS assembles this datainto detailed cost analysis reports to sup-port corporate-level forecasting and deci-sion making.
Ford started VCAPS in 1993 and builtit with VisualWorks and GemStoneSmalltalk. VCAPS is now being main-tained with a small staff and is to bereplaced with a newer system.
The VCAPS project challenged us twoways. First, the analysts wanted modifica-tions and new functionality before eachrun. Constantly changing requirementskept us in reaction mode. We never caught
up. Second, the system needed to be runin a limited span of time. But the systemtook a long time to process and requiredlengthy manual input before producingfinal output. A bug could waste precioustime by requiring a rerun.
XP offered us a unique combination:agility to meet the volatile requirements ontime and quality to avoid the dreaded rerun.
We began XP with the planning game.It was a failure. Customers and manage-ment were unaccustomed to negotiatingschedules. The commitment schedule pro-duced was perceived as lacking credibilityand utility. We had to swap in MicrosoftProject schedules, which could be modi-fied without large meetings and could pro-duce the kinds of artifacts managementwas used to seeing and taking action on.
We continued by adding a few unit tests.Automated unit testing was an enormoussuccess. After a year, we had 40 percenttest coverage and management had mea-sured a 40 percent drop in bug reports. XPwas being noticed.
We solved problems by adding XP prac-tices. Tests enabled continuous integrationand small releases. These allowed us toroll in collective ownership and refactor-ing. We were working toward simpledesign. Building momentum, we tried pairprogramming. We had to work hard to getpair programming going. Our developersfound it awkward; it took a while tobecome comfortable.
After a year and a half, the decrease insystem failures had reduced the number ofemergency releases to a point where cus-tomers and managers noticed far greatersystem stability. Overall, XP was very suc-cessful in our environment.
Team: 12 programmers, 17 totalApplication: cost analysis systemTime: six years
October 1999 77
Tariff System: Tests You Can ReadRob Mee, Independent consultant
Tariff System is a subsystem of a largeSmalltalk/GemStone project at a majorinternational container-shipping company.Using XP practices, Tariff System wastaken from inception to production inthree months by a team of three. Theresulting system proved to be unusuallystable and easy to maintain.
At the outset of the project, the teamresolved to adhere to several core XP prac-tices: always program in pairs, use the sim-plest design possible, refactor aggressively,and write extensive unit tests. All of thesepractices were very effective. One XP ideathat initially seemed far-fetched was writ-ing tests before writing the code that sat-isfied them. We were surprised to find thatin fact this helped bring our designs intofocus, enabling us to work more quickly.
Another practice we employed from thebeginning was collecting requirementsfrom users in the form of user stories. We
had mixed results with this. As program-mers focused on coding, we found the roleof facilitating and negotiating with usersdifficult. More important was the fact thatusers needed lots of help writing storiesthat were both relevant and unambiguous.In the end, we felt that perhaps XP wasmissing a project role. We needed some-one from the development team whoseprimary focus—and particular talent—was interacting with users.
In our efforts to refactor test cases and fix-tures, we discovered that creating little lan-guages for our major domain objectsdramatically improved the readability andbrevity of our test code. It also practicallyeliminated the time we spent thinking abouthow to create object instances when writingtests. We defined grammars for about ten ofour domain classes. Here’s a simple exam-ple used to construct a Service Offering:
newFromString: ‘from Oakland toTokyo shipping toys: 20ft containers $500;40ft containers $1000’.
The constructor uses a parser, automati-cally generated from a grammar, to pro-duce the domain object. The code toinstantiate this object using standard con-structors would have taken many lines,would have been difficult to read, andwould have distracted from the test caseitself.
Eventually, we discovered that wecould combine the individual domain lan-guages into a larger description of the sys-tem as a whole, which proved to be avaluable tool in the expression of func-tional tests.
don’t have to shuffle the remainder of the iterations,you just put it in the pile. One or two weeks later, ifthe story still seems urgent, the customer will pick it.
Planning one iteration at a time also introduces apleasing self-similarity. At the scale of months andyears, you have the stories in this release and then thestories in future releases. At the scale of weeks andmonths, you have stories in this iteration and then thestories remaining in this release. At the scale of daysand weeks, you have the task you are working on nowand then the rest of the tasks in the iteration. And atthe scale of minutes and days, you have the test caseyou are working on now and then the rest of the testcases that you can imagine.
X P is by no means a finished, polished idea. Thelimits of its application are not clear. To try ittoday would require courage, flexibility, and a
willingness to abandon the project should your useof XP be failing.
My strategy is first to try XP where it is clearlyapplicable: outsourced or in-house development ofsmall- to medium-sized systems where requirementsare vague and likely to change. When we begin torefine XP, we can begin to try to reduce the cost ofchange in more challenging environments.
If you want to try XP, for goodness sake don’t tryto swallow it all at once. Pick the worst problem inyour current process and try solving it the XP way.When it isn’t your worst problem any more, rinse andrepeat. As you go along, if you find that any of yourold practices aren’t helping, stop doing them.
This adoption process gives you a chance to buildyour own development style—which you will have todo in any case—to mitigate the risks should XP notwork for you and to continue delivering as youchange. ❖
Reference1. S. Prowell et al., Cleanroom Software Engineering,
Addison Wesley Longman, Reading, Mass., 1999.
Kent Beck owns and operates First Class Software,your typical one-person consulting company mas-querading behind a fancy name and an answeringmachine. In addition to two books and 50 articles, heis the author of the forthcoming Extreme Program-ming Explained: Embrace Change (Addison WesleyLongman, Reading, Mass., 2000). Contact him atkentbeck@csi.com.
Team: three developersApplication: shipping tariff cal-
culation systemTime: three months
