CI Tools and Best Practices in the Cloud

Continuous Integration

Subscribe to Continuous Integration: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Continuous Integration: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Continuous Integration Authors: Elizabeth White, Yeshim Deniz, Pat Romanski, Liz McMillan, Mehdi Daoudi

Related Topics: Continuous Integration

Continuous Integration: Article

Extreme Programming

A (Fr)Agile methodology

The Agile Manifesto is the product of 17 smart, well-meaning developers who met in February 2001 to discuss problems in software development. The list of developers included Kent Beck, Alistair Cockburn, Martin Fowler, Ron Jeffries, Robert "Uncle Bob" Martin, and Dave Thomas - people who have all made substantial contributions to software development.

During the three days the group met, they spoke of the frustration they had with writing software and found a great deal of common ground. From their discussions, the Agile Manifesto emerged in its current form.

"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more."

"Agile programming" is the name given to any methodology that subscribes to the Agile Manifesto. The most well-known example of agile methodologies is the set of 12 principles stated by Kent Beck in his book, Extreme Programming Explained: Embrace Change. In this article, I'll explain what Extreme Programming (XP) is and why I think it is so profoundly wrong-headed.

Beck states that XP is founded on four "values": communication, simplicity, feedback, and courage. Beck says that these values are worked into the following XP practices:

  • Test-driven development requires that tests be written before the software is written.
  • The Planning Game is used to derive "user stories" - extremely brief reminders to the developers to have more in-depth conversations with the customer.
  • Whole team (previously "on-site customer") requires a continuously available customer to answer questions. This is necessary since XP "requirements" are so vague as to be almost nonexistent.
  • Small releases assure that every 1-3 weeks a new version of the developing software is released.
  • System metaphor provides a way of thinking about the application that takes the place of a documented system architecture.
  • Simple design is guided by the aphorism: "Do the simplest thing that could work." Developers are highly discouraged from actual system architecture, which the extremists pejoratively term "Big Design Up Front."
  • Emergent design is the hope that an overall system architecture will slowly coalesce, based on individual design decisions and an understanding of the system.
  • Refactoring is the process of rewriting code as more requirements are introduced and the overall design "emerges."
  • Collective ownership prohibits individuals from owning code. Instead, developers are encouraged to make changes to (refactor) code written by others in an attempt to ensure that the best software is written.
  • Pair programming requires that all production code be written by a pair of programmers working on one computer.
  • Continuous integration eliminates the problems of late integration by integrating code several times a day.
  • Sustainable pace forbids developers from late-night pizza and Mountain Dew sessions, insisting that developers work no more than a 40-hour week.
  • Coding standards, the last of the XP practices, make all the other practices easier to implement.
Why is it called "extreme" programming? According to Beck, his inspiration was the idea of "turning up the dial" on readily acknowledged best practices in software engineering. Here's a sample from Beck:

"If code reviews are good, we'll review code all the time (pair programming). If testing is good, we'll test all the time (unit testing), even the customers (functional testing). If design is good, we'll make it part of everyone's daily business (refactoring). If architecture is important, everybody will work defining and refining the architecture all the time (metaphor)."

On one of the XP wikis, one impassioned fan put it like this: "XP is the Jonathan Livingston Seagull of programming!" He's not alone: XP is now a mini-industry, spawning dozens of XP books and a core of fervent followers.

But does XP have it right? If something is good, does "turning the knob up" to extreme levels really make it better? It's an important question, for this is the guiding principle behind all of XP's values, practices, and activities.

A logic professor of mine in college used to say that a helpful activity in judging the validity of an assertion is to apply it to a different field. If the principle is really universal, the conclusions should be similarly acceptable. And here, XP fails fatally. Let's try this "wisdom" in some other areas.

"If sleep is good, we should sleep all the time."
"If talking is good, we should talk all the time."
"If working is good, we should work all the time."

These are absurd conclusions: clearly, Beck's guiding principle is not universal. But it may still be that in this particular field of endeavor - writing software - a happy confluence has occurred and that this particular set of practices just works well together.

To determine this, argumentation is futile. If the practices work, the results should attest to them by a success rate that is above the norm. Unfortunately, in reading the impassioned writings of XPers, it becomes clear that the advocates feel that the "higher truth" of XP should be self-evident and does not need to demonstrate actual project success. This may explain why there are so few actual case studies of XP projects. For guidance, we must use the "poster child" of XP projects, the Chrysler Comprehensive Compensation (C3) project, guided by Kent Beck, Ron Jeffries, and Martin Fowler. Certainly, if anyone knows XP, these are the people.

The C3 project was an attempt to take an existing mainframe system and port it to PCs. Chrysler was concerned about the Y2K bug and felt they needed a replacement in case the bug turned out to be real. The project began auspiciously enough in 1995, judging by some of the contemporaneous quotes of the XP advocates who worked on it:

"The best software development team on the face of the earth!"
- Chet Hendrikson

"I'd never have said it, but it turns out payroll is so complicated that it is very interesting finding the inner simplicities that make it possible to write a program that works. Objects are perfect for it. Smalltalk is perfect for it. That's just part of why we call C3 Payroll the best project in the world." - Ron Jeffries

Magazine articles with the XPers took up the refrain: XP had proven itself. Alistair Cockburn, talking with Ron Jeffries in February of 2000, put it like this: "As we talked, I asked Jeffries how success on the C3 project translated into XP use on other Chrysler IT projects. His grin told me all I needed to know."

Well, maybe not quite all of what needed to be known. In February of 2000, the XP faithful were stunned by this announcement on the XP wiki:

"As of February, 2000, the C3 project has been terminated without a successful launch of the next phase."

The "next phase" was something beyond a simple pilot program, the most that the C3 project was ever able to achieve. The much-vaunted C3 project, the best project in the world, was a failure. Again, comments from the XP wiki:

" Daimler Chrysler these days the terms, "C3", "Extreme Programming", and especially "the Planning Game" ...are now unutterable by anyone wishing management to take them seriously..."

" the view of DC's [Daimler Chrysler] management, C3 was a disastrous project and never the like shall be seen again there."

Given the devastating failure of XP in the C3 project, have the XPers moderated their claims? Not at all. The problem, some of the XPers involved in the project stated, was the customer and not the methodology at all. Undaunted by failure, the XP industry continues to churn out books, articles, and unsupported claims at a prodigious rate.

Unable to use statistical analysis - or even numerous anecdotal successes - to bolster their claims, XPers have lapsed into New Age talk.

"Unacknowledged fear is the source of all project failures."
- Kent Beck and Martin Fowler

"Why do we need a software process? For the same reason that we need government, taxes, and laws: fear." - Kent Beck and Martin Fowler

"I had an epiphany. I went back where Kent was and said that we were just ?balancing hopes and fears.' We had focused on our hope that we could launch the system as planned and our fear that we wouldn't. Kent told me that I had just ?snatched the pebble from the master's hand.' We knew what had to be done..." - Chet Hendrikson

Opposing XP today will likely get you branded as an obstructionist, someone who just doesn't "get it." Shorn of actual project success to point to, the XPers have "turned up the dial" on the rhetoric. Alan Cooper, the creator of Visual Basic and author of such books as The Inmates are Running the Asylum, had a discussion recently with Beck about XP.
Beck: For all its Dilbertesque qualities, I'm still proud of having "Embrace Change" in the title of the first XP book. I've consciously decided to give up the ability to predict the future.
Cooper: I see that in XP. It's an abdication.
Beck: Is Zen an abdication?

No, Kent, Zen is a philosophy of life. Wrapping a failed methodology in high-sounding terms doesn't make it profound; it simply obscures the issue. I believe we must demand more of project methodologies than cultish phrases and mystical patter. The ability to repeatedly produce successful software projects is a thing of extreme value - to both programmers and the clients they produce software for. Is it too much to ask that a methodology that promises this actually works?

More Stories By Hal Helms

Hal Helms is a well-known speaker/writer/strategist on software development issues. He holds training sessions on Java, ColdFusion, and software development processes. He authors a popular monthly newsletter series. For more information, contact him at hal (at) or see his website,

Comments (5) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
John Paul Ashenfelter 12/17/04 10:03:47 AM EST

I'm saying what the XP folks say -- XP advocates say that if testing your programs is good, any time I program I'll constantly test my programs. So to continue the analogy -- anytime I eat, I'll eat healthy. XP doesn't suggest testing, etc 24x7 -- just while you're programming. But this is all academic because the analogies are all not quite right.

But speaking of academic, how about taking a look at actual research about XP instead of using analogies to argue? Or Alistair Cockburn's decades of research on programming methodology that support Agile methods for many types of applications. Methodologies are certainly a tool, and though many folks take them to a religious extreme, the tools are still useful -- especially if you truly know how to use them and have a good idea about their benefits and drawbacks.

My fundamental criticism of this article was that even a few minutes with Google can find plenty of research that is starting to show the true benefits of Agile methods (XP as well as others). Don't want to read research reports? Robert Martin's Agile Software Development book has several real cases describing how Agile methods have been used successful in specific instances. Or Alistair Cockburn's distallation of years of methodology research.

And as an aside, what's wrong with a side industry in XP books and training? Seems like there's a side industry in FLiP and Fusebox books -- and there seems to be nothing other than anecdotal evidence to back up the claims for the FLiP methodology. I actually like Fusebox and parts of FLiP -- but I've yet to see *research* showing it's successful.

You can actually write a very similar article to this one by replacing the words "Agile" and "XP" with "FLiP", changing a few names, and similarly criticizing a different set of precepts -- which would be an equally useless (at best) or misleading (at worst) article.

Jeff Peters 12/14/04 10:31:25 AM EST

JPA: Your logic isn't sound at all. You're simply saying, "If daily exercise is good, we should exercise daily", as opposed to, "If daily exercise is good, constant unceasing exercise is better." The same holds with your eating analogy: Eating healthy food may be good, and eating healthy food on a daily basis may be fine as well, but eating healthy food constantly without reprieve would certainly not be recommended by any physician or nutritionist.

John Paul Ashenfelter 12/09/04 09:34:01 AM EST

Speaking of google, how about a quick search for the academic research on XP, Hal? Maybe start with the reearch papers Laurie Williams is writing? One good example is the longitudinal study of before and after XP was implemented at SABRE

And while XP is an Agile methodology, all Agile methods are not eXtreme Programming -- there are many other options (scrumm, crystal, etc).

And I bet your logic professor is cringing at your use of "logic" to prove XP is bad. How about "If eating healthy is good we should eat healthy all the time" and "If getting daily exercise is good we should daily exercise all the time".

Chris Phillips 10/23/04 03:31:47 PM EDT

Oops. Always Google first.

Chris Phillips 10/23/04 03:28:07 PM EDT

I'd really like to read the rest of that conversation between Beck and Cooper. Can you link it? or give us the reference please.


Chris Phillips