Extreme Methodology

I think ExtremeProgramming is a serious methodology, which I have been citing to the people around me. I would think it would be a mistake to give it a euphemism for a name if anyone were to do that. If it takes unnecessary damage from its extreme name, then give it an unapologetic natural name to indicate it really is the natural way of working. The prefix Extreme best takes a gerund - a verb in 'ing' form. It plays upon the extreme skiing and extreme snowboarding terms. And it is extreme programming, it is a methodology of living programming and designing programming, and documenting programming, and offering programming as the most serious part of software creation. (Only someone who was afraid of facing their fear of being called "JustaProgrammer" would call this ExtremeSoftware. -- KentBeck)

Extreme programming quite possibly works in more than one setting, and should be put forth as a serious contender to documentation-based methodologies. I vote it as a valid one of the MinimalMethodologies. I like the ExtremeProgramming methodology, it fits my definition of a big 'M' methodology, it pushes a given philosophy to its natural conclusion and stands behind that conclusion. It has been used by more than the ChryslerComprehensiveCompensation project (but not as vocally defended or as well documented) so it has wider prior art. I find it interesting to defend, even not having ever used it. -- AlistairCockburn

I like what I have read so far about ExtremeProgramming. I just wonder whether it can be assumed to be universally applicable or whether there are certain development scenarios in which it would be best not to try this form of process. -- MichaelFeathers

I was meeting today with another Chrysler project and one of the people asked me this question, relating back to the old days. I found myself answering that while some of the details might change, I'd adhere to, and so on, as my technical base would support. In short, integrating my present and past experience, I'd start by using the ExtremeProgramming practices to the maximum degree possible. As always, I'd adjust when we were too extreme. --RonJeffries

I have been seeking to apply 'as lightweight a process, as simple a commitment, as much refactoring' increasingly, as best I know how, to a large mixture of commercial projects for over ten years. There is still a great deal to improve and ExtremeProgramming is one of the few methods/cultures/case-studies to come along that is really helping. In my view no 'development scenario' anywhere can afford to ignore what this Smalltalk team discovered when they took development to the 'extreme'. --RichardDrake

I've been thinking about ExtremeProgrammingAbstractions? as a way of ScalingExtremeProgramming. The idea that one team might play customer to another team in a tree hierarchy seems appealing to me in a theoretical way. The thing about XP is that it's really two things: Extremeness, and programming. Programming's been analyzed to death, but the extremeness angle seems like it can be distilled and applied to processes that fit a similar niche to programming. In other words, what if we can apply extreme principles to different types of teams, developer teams and customer teams And to make it scalable, some teams are both developers and customers.

It seems to me that in the interface between developers and customers, what's really going on is negotiating scope, and delivering the product. Let's say for argument's sake that there is team A who talks to the real customer, and team B who talks to team A. Customer says to team A, "I need system S." Team A says to team B, "We're building system S. We need feature X." Team B delivers feature X. Team A integrates that into their system and delivers system S.

Possible non-extremeness factors that could screw this model up:

• In the end, team B really answers to the real customer. Team A, being the middle man, slows down communication and eliminates XP's rapid feedback.