This is a nice article - very straight froward, easy to understand.However, there was no mention of any organization that have implemented XP.
The author said, "Many of the concepts found in this lightweight method of development have been implemented into the software shops without even the awareness that they were XP techniques" Can you give examples of companies/organizations that are using or has used XP?

First off, I agree completely with the comments that XP wasn't "one of the first iterative" processes. For a good history of iterative development, have a look at the article from Craig Larman and Vic Basili at:

http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf

Secondly, my background is in business systems which likely has an influence on my views about agile development and XP.

] In 1-2-3 how XP is different from Rational Unified Process (RUP)?

1) XP focuses on one main artifact - the executable software that actually delivers business value to the Customer.

2) Testing at all levels is formalized into the process, and various frameworks are freely available.

3) For the price of one seat of Rational Enterprise Suite, you can buy a pretty big pile of index cards! ;)

] So, IMHO, what XP actually has introduced are 2 things:
]-1- pair programming -2- daily meetings

No one has ever said that the XP practices are new in an of themselves. The process originated when Beck looked at all the things that had worked for him over the years, and he figured a way to put them together. The end result is greater than the sum of its parts. BTW, Daily Stand-up Meetings came from Scrum.

] Phases of XP ------------ Planning - User stories,...

Those aren't phases. Planning in XP happens on a continual basis. By using short iterations (1-3 weeks), you're able to react to changes (which always occur) very quickly.

] Consultants and business analysts should damn well do
] their jobs and get workable specifications from customers,
] it's cheaper and more maintainable overall to develop a
] flexible, well formed design than to rush out brittle,
] naive XP code and try to understand/refactor the mess,
] at much greater cost later on.

Please define a workable specification. I agree completely that a flexible, well-formed design is cheaper and more maintainable, provided that it isn't speculative. The whole point of refactoring is to move the code base towards being cleaner and more maintainable long before it is shipped to production. The refactoring process happens in minutes, hours and days, and much less frequently in months or years.

Note as well that I advocate doing design work. I do not think that attempting to design the entire system in detail up front is valuable. However, my current team does whiteboard sessions constantly to work out design issues. We also work constantly with the Customer to work out requirment issues, since our system encompasses several lines of business.

We have been using XP on this particular project for 2 years, and we're pushing releases out to production every 3-4 months. I personally have been using XP for 4 years, and I can't imagine using another process. I'm also pragmatic about applying it - sometimes pair programming simply can't be sold. OK, then we'll do formal code reviews, and pair in a less formal way when we need help. One thing I have insisted upon is unit testing - there is simply no excuse for not doing it. Everyone pays lip service to automated unit testing, but very few people actually do. Fortunately, that number would appear to be growing.

] IMHO a consistent logging stragegy and self checking
] code are far more valuable than unit tests...

I log too, and find it valuable. Now, though, writing code without unit tests feels like being on a trapeze without a net.

] I like pre-release testing too, however I prefer to input
] real user data rather than contrived data since real users
] are much more creative at accidently or deliberately
] breaking a system e.g. scanning bar codes as money
] amounts!

Absolutely!! We do this as often as possible, and have 3 dedicated QA people who test our system. There is no substitute for actual use of the system to provide the feedback necessary to deliver a good product. There's nothing in XP that says you shouldn't do that!

As for XP at Chrysler, I don't know enough about it to comment. I do know about XP at the places I've applied it, and it has been successful.

Agreed classic XP sucks.

As I think they say in XP (ironically), if something 'stinks' it probably needs refactoring e.g. pair programming, frequent unit testing *, frequent refactoring, customer representative on-site, no real design etc...

* BTW how do you test the test cases and is this recursive? What about the test case development cost, including extra test case costs, from refactoring?

Consultants and business analysts should damn well do their jobs and get workable specifications from customers, it's cheaper and more maintainable overall to develop a flexible, well formed design than to rush out brittle, naive XP code and try to understand/refactor the mess, at much greater cost later on.

I like pre-release testing too, however I prefer to input real user data rather than contrived data since real users are much more creative at accidently or deliberately breaking a system e.g. scanning bar codes as money amounts!

IMHO a consistent logging stragegy and self checking code are far more valuable than unit tests, since they are also valuable for catching and rapidly locating live issues e.g. I've even spotted rare, unreproduceable data bugs in other systems with this approach, so proving my software was OK!

BTW I use log4j, with a custom wrapper class, to enforce logging consistency, but haven't upgraded to the latest version because of the stupid new Level class change.

I have chime in here:

Not knowing much about XP up to a couple of days ago when I read this article, I was excited but wary about its principles. However, I have new found a wonderful and utterly readable book that has brought me back to my senses. It is called "Extreme Programming Refactored: the Case Against XP", by Matt Stephens and Doug Rosenberg from Apress (http://www.softwarereality.com/ExtremeProgrammingRefactored.jsp).

It does a wonderful job of analyzing XP's shortcomings and why they are shortcomings. I am an avid proponent of automated testing and am constantly searching for ways to improve customer/developer communication and lessen the onerous weight of written design documents, but almost anything to an extreme can cause problems. Even water will kill if drunk constantly!

The Chrysler debacle is held up by XP proponents as a shining example of why XP works. However, the project was cancelled by Chrysler in February 2000 because it wasn't delivering - it was a payroll system that was only paying about 1/3 of the employees. XP itself says, "At the end of the day, if the program doesn't run and make money for the client, you haven't done anything." Chrysler decided they hadn't done anything. Ask an XP proponent about that failure, and you'll get a lot of spiritual-sounding mumbo-jumbo and trite phrases. One good one is from Beck himself: "XP is an emotional experience." Thanks, but I have a life outside work to provide my emotional experiences. I've read a lot on XP from people on both sides of the argument, and I've noticed that XP's proponents use much more spin and hype than its opponents. Here are some references for why you shouldn't believe everything you read about XP. Unfortunately, the first one is both the best and, I believe, only available to subscribers of CFDJ:
http://www.sys-con.com/story/?storyid=46792
http://members.cox.net/cobbler/XPDangers.htm
http://www.wired.com/wired/archive/11.09/xmen_pr.html

Mostly good article - except ... "XP is one of the few methodologies that actually strives to deliver high quality code that meets the customer's expectations"

I cannot think of one software methodology that makes a contrary claim. Don't all methodologies of note that strives to deliver high quality code and meet the customer's expectations? Otherwise, is it even a viable methodology? Can anyone name a serious methodology that looks to skip either quality or customer satisfaction?

One more thing: I am *not* directing the comments above to the author, but rather to the editors who chose to publish this fine, if outdated article.

Please, not another article rehashing the same, tired old XP sales pitch. As one commenter said, this would have been novel four years ago. What are we going to have next, another article about JUnit? While this was written well enough, it does not provide a balanced view of the pro *and* the cons of XP and where it is and is not applicable. Anyway, XP and JUnit seem to be two topics that people write about when they have nothing else important to say.

Methodology is the study of methods. XP is a development *method*.

I struggle with XP. When it first came out it rubbed me completely the wrong way. I read a number of articles and Becks small book entitled "Extreme Programming Explained". A few years later, and based on my more traditional view of structured analysis and development, I find one thing true: do what works for you. In my humble but deadly accurate opinion Use Cases (and "Use" is not short for "Usability" I would like to clarrify) and UML ar the most helpful and misunderstood tools of the trade today and I highly recommend that programmers just slow down enough to strap on those well honed tools. Having said that, the reason XP doesn't really work is two "reality based" fundamentals:

1. Companies sponsoring projects are looking to contain cost. This is a large downfall of XP since based on it's vague (by nature) requirements you end up unable to nail down costs. The corporate world is demanding fixed bidding every day and the interrative style of gathering and defining requirements keeps the cost related to actual work tasks unreasonably fluid.
2. I watched an entire local consulting company collapse due to the implementation of a version of "XP". Reason: If I pay you for "XYZ" then I don't want to sacrefic "X" because you didn't understand the girth of "YZ" when we started. What would you do if you went to buy a car for $X and in the end $X only got you the tires you are looking for? You would want your money back and try to find a dealer willing to listen up-front before you sign-off on the bottom-line. Nobody likes sacrefic. Nailing down requirements and scope is difficult. The answer is not disguising that short fall with a process that accomodates it.

I realize these are heated-sounding comments - but my hope is that people get inspired to tell stories that prove me wrong.

My proposal: Learn UML, Document your project's analytical phases well, come to a team agreement on Quality, Cost and time and STICK TO THE PLAN!

If you are looking for something more flexible and interrative then examine the Proj. Management Guide to the Body Of Knowledge (PMBOK) cyclical models. You will find what you are looking for.

If you want to see an explanation of that - take a look at my cyclical process ( http://www.enginpost.com/resume/Pro%20CDP.pdf )!

Good luck everyone and happy coding!

Dave,

There is no harm in developers writing user stories but its better the users write it themselves, because this helps them crystalise their thoughts and precisely state the problem that needs to be addressed.

Regards,

Sridhar Pandurangiah

Sridhar,

First, I'd like to thank you for addressing precisely what I was asking. I appreciate your digest, specific and from what I know - full answer.

From my observations on how UML appeared and matured as a methodology (engineering culture) an effort that RUP had undertaken was to give a perspective on how to use UML in practice. RUP and UML both have mutual references and one supports the other.

An Actor as a UML entity is present to facilitate the fact that Events in the system being initiated in a timeline. Further, statefull classes rely on Events as a vehicle that drives Class through it's lifecycle from State to State. Actor often present in Sequence diagrams.

Most importantly, RUP introduced the concepts of iteration and incrementation as guiding principles of the project process.

Once again, I agree with your comment that RUP is a commercial product that means marketing had influenced the expression of engineering experience and ideas. Though, I seek for agreement, the influence was not deadly.

In most of the responses to the discussion, and if I'm not mistaken, the comments made relate to the subject of how to bring Business Requirements (let's just name it as such in a very broad meaning of it) into the Engineering Environment. In other words, how to adequately express business needs in engineering terms.

Not a trivial task indeed, and I hope again to find agreement that generally speaking the same business needs may have substantially more then a single engineering perspective.

There we have flavors in approach and various success \ failure outcome.

Undeniably, I'd like to refer to comment Eduard makes, in my mind the decisive factor in the end always is the actual team you have to lead in a project as team members are irrational in their nature no matter what rational (or XP) methodology you attempt to go with. To me it's like tools, machinery and whom did you put to use it.

Both RUP and XP are, in my mind, an attempts to formalize the project as a process, yet delivering a project would still be an art of navigating it through.

The strong point made in XP is the timing of writing Test or Usability Cases (not always necessarily interpreted as identical). RUP shies away from it, while UML and OOAD folks stress the vital effect of Use Cases complemented by Usability Cases which is an Instance of Use Case in some UML interpretations.

Overall, I'd like to mention, I've seen businesses spending $mils on all Rational Corp had to offer with little engineering benefit. Quite similar to what happened with J2EE products. Naturally, we see a light-weight alternatives as APM (Apache/MySql/PHP etc.) and XP filling the niche.

Often frustrated by heavy duty monsters that RUP and J2EE / .NET are on one hand and pressed by the reality of succeeding in market place accompanied by a sense that there should be a way of producing better results with lesser overhead - in one word, a way to be substantially more efficient - engineering community finds ways and turns to alternatives with a promise as XP in my mind definitely is.

---------------------------------------------------------
Sridhar:

In UP you write the code and then test it.

There is no pair programming in UP, XP recommends pair programming
---------------------------------------------------------

That is true. Though as one open-minded follows RUP delivering project inevitably both do occur implicitly as XP suggests.

Quite similarly as people have been driving their projects incrementally through iterations before RUP mentioned it.

Eduard,

---------------------------------------------------------
So, IMHO, what XP actually has introduced are 2 things:
-1- pair programming
-2- daily meetings
Both are social aspects, and it was not possible to convince anyone of their benefits to the development process.
---------------------------------------------------------

---------------------------------------------------------
we used to write the user's manual one step ahead of design and coding we
always fulfilled the customer's expectations.
---------------------------------------------------------

That is, in my mind, a different viable perspective on how practically present Business Requirements, Concepts in Engineering perspective. RUP does identifies the focus area, except I was never taking the Inception literally. Once again, just as your team is a subject to a social aspect, so is the team of Business Analysts you work with.

Deke G

---------------------------------------------------------
Around my company, nobody mentions XP if they want to be taken seriously.
---------------------------------------------------------

To my believe, in environment where engineering culture is present, people are always open to see new tools and ways regardless of marketing label. Methodology, unless I'm mistaken, is a kind of a tool.

Thank you all.

Gratefully,

Oleg Kirshon

The topic is very limited, current trends for software engineering is towards the 'Agile', but not 'why XP'. XP is one of agile ways. If you talk this topic 4 years ago, might be the perfect timing. I'd rather read an article 'Why Agile?'.

XP discredited because of Chrysler? One of the examples of how XP could be used to save a project WAS Chrysler, or so I have read...
http://www.xprogramming.com/publications/dc9810cs.pdf

I thought XP had been thoroughly discredited following the Chrysler debacle. Around my company, nobody mentions XP if they want to be taken seriously.