I couldn't possibly subscribe to using "extreme programming" for the very simple reason that it's a really stupid name! It conjures up images of banging out uber-complex C++ code while snow-boarding down the virgin snowy face of a desolate mountain (on one leg), and undertaking negotiations for a multi-trillion pound investment program (via a leading-edge satellite phone) in-between fighting off hoards of rabid bears.

The other reason is that "extreme programming" basically translates as "doing your job properly". It is nothing more than that.

I've been "doing my job properly" (or at least trying to) for years, and I don't need someone to come along and stick a label on how I work. I don't have a "methodology" for "doing my job properly". Unless you call the combined ideas of common sense, planning, attention to detail, and quality a "methodology".

"Extreme programming" (I cringe every time I write that) is just like UML and SSADM (remember that?) and Yourdon (showing your age now, eh?), and a multitude of other methodologies and ideas for how we should do stuff - ie - it's just a way of selling books!

Have I wasted my time coding with lions, cutting code whilst free falling, and bungee coding, to name but a few.

Oh my, extreme programming never works, it is just management that like the name, so yes people just claim they do it - but only the truly foolhardy actually do it.

The Mythical Man Month is so much closer to the actuality of development, what we have are people, who if you are a good developer you use as code PAs, you have to make the project manager work for you, not the other way around, whilst leaving them with the impression that they are in control. Sometimes I think that development is more about people management than actual code, managing people out of the way, so you can concentrate on the project at hand.

Pragmatic programming is a better style than extreme coding. Extreme coding assumes an equal level of skill amongst developers and a hive mind, it is off in the land of the fairies and middle management. There are just so many examples of why extreme coding does not work and produces more trivial arguments about tab spacing and looping variables than it does actual workable code.

But yes, we all practice extreme coding, and none of us speed, drink or smoke, and we are all CofE on British Airways flights, and we don't use a sprinkler at night during a drought warning.

There are, of course, some good principles in Extreme Programming, despite the ludicrous name. But like most methodologies, in practice people pick and choose the bits they like.

The least popular bit in my experience is pair programming. In fact I can safely say that I've never seen it in the real world. Possibly this is related to some programmers' tendencies to be a) mildly autistic and b) smelly.

By the way Rich, UML isn't a methodology. It's just a diagramming convention, which is not the same thing at all.

"...UML isn't a methodology..."

Ta for the tip, but yes, I know :-)

I was just throwing it into the fire as yet another example of being told how to do stuff. In the case of UML (as is so often the case and highlighted by your "paired programming" example), reality doesn't live up to the hype. It's the king's new clothes all over again and just someone trying to sell as much vapour ware as they can before it falls out of vogue.

The problem with pair programming doesn't come from the programmers - it comes from the management. It's 'obvious' that pair programming is just a waste of resources.

Actually pair programming is one of the bits of XP I actually like the sound of and would be happy to see trialled at my place of work. Except maybe on an annoying Thursday afternoon.

All this talk (book titles, etc.) is just to apply the name-of-the-year to a practice that has been ongoing for eons. Sounds like hype in another set of clothes.

Who knows next year it will be "magic interaction" for all I know (you heard it here first!).

Did anybody else's tea come out of their nose when they read that?

I don't know if this is even worth of commenting? We tried XP and SCRUM and agile and a couple more which don't have current "new" acronyms in 70's with 400+ developers / programmers in a controlled environment! AND the result - some methods work in some special cases but no magic was found! And the same methods didn't work in all the phases - actually the agile design did show a lot of benefits when moved out of site but that has been known a long time, isolate the design group somewhere without interruptions you get better results. Code development did work well when the roles and requirements were well defined, duh! So, before any of these "new" methods are tested and proven in a CONTROLLED environment, I think they really are just fluff and, as some have said, there to make money and fame.

Agile has caused more pain than good for QA guys. Management want to know the state of the application based on tests run, passed, etc. Agile really doesn't support this.

I really felt agile was like a developer love fest where they go; "yeah, this week this is cool", rather than actually thinking about product. It supports week in week out hackfest.

Biggest. Pain. Ever.

I agree that QA can often be left on the side of the highway looking for its own ride to Fresno when deadlines are looming and people are screaming for working code they can point to and say we accomplished something.

However, in real XP, tests are integral to the process, not left to fend for themselves. I define the tests, which when passed, define success. To quote Kent Beck,

"In fact, in XP the acceptance tests for a user story are specified by the project stakeholder(s) either before or in parallel to the code being written, giving stakeholders the confidence that the system does in fact meet their requirements."

The onus is on programmers to develop appropriate unit tests. The problem is, they may not be the same people defining the requirements. Flexibility in programming is ultimately important so that we can respond to changing requirements without having to repeat an entire iteration in our development lifecycle.