Software Reality
Extreme Programming

Site Map Search

XP Central
Forum
Case Against... Songs
Other Critiques

Use Case Driven
Use Case Driven Object Modeling with UML: Theory and Practice
Get from use cases to working, maintainable source code. Examples use Spring Framework, JUnit and Enterprise Architect

Agile UML
Agile Development with ICONIX Process
A practical subset of agile development techniques, illustrated by example

Get Controversial!
Extreme Programming Refactored
Extreme Programming with a dose of satire
Available now:




XP Central

Latest Feedback

Some people noted that almost all the feedback listed here is positive. They seemed surprised that no one had sent me any emails disagreeing with the "Case Against..." articles. Seriously, I scanned back through my Trash folder and couldn't find any. If you're interested, there's plenty of vitriol and anger here though (comp.software.extreme-programming).

 

In response to the "XP From the Trenches" article by Rich Camden - this message was sent by an XP programmer who wishes to remain anonymous:
Rich,

I, like you, have sort of unwittingly stepped into XP without much negativity at the start. In my case it's rather awful, I'm in a 6x13 room with 6 workstations. It's a large company, making money, and there are empty rooms all over the place. The pairing is near unbearable. I really think you were somewhat soft in the article. This project has reached maintenance in some places and the task of pairing while digging through unkown code is terrible. People discover code and explore it in very different ways and I found most people do it very differently than I prefer. It always ends up in either me forcing the pair to go where I want, or just lazily day-dreaming while I pretend to "watch". In either case only one of us is happy. Here's an example of "pair" written code. I found 500 instances of this mindless stuff today:

if ( mybooleanvar == true ) ...

I know it's nitpicky, but any normal developer would just write:
if ( mybooleanvar )

The fact that there are over 500 examples of this shows one thing, a serious cut-n-past nightmare. Instead of good things permeating the code, you end up with bad things all over the place, and your stuff gets all mixed in with their stuff so you are just as guilty. What happens is that the pairs are in such a hurry to finish the card and get away from each other that they mindlessly cut-n-paste to meet the immediate requirements ( what's needed for today ). Another thing that nobody seems to be willing to point out is that it is just weird to sit right next to the same people, nearly touching shoulders, for months at a time. I don't know about the British, but I like a little space between me and other people. There is also ergonomics. Just a year or two ago I thought it was correct to have a nice chair and keyboard just positioned right, same for monitor. Constantly moving positions in pairing makes this impossible.

As far as I can tell, XP is the equivalent of the Chinese cultural revolution. Everything is turned upside down. Even the agressive anger and unflinching dogmatism of XP people is similar to communists. If you disagree, it's always your fault for not following the practice correctly, but the XP ideals are held up high, like some cult, but just as unattainable as the Marxist state, ending up in some type of horror where people pretend to like things they hate. Honestly, if I had known that I'd be herded into a crowded room and treated like a child ( playing games, smelling code, etc ). Just curious if I'm the only one who felt this way. For example, when the team lead suggests I "pair" or "take a pair" I nearly lose it. It's just so mamby pamby cumbaya touchy feely that it nearly makes me puke. Some of the other developers even say things like "I need a pair". Oh yuk. I need a barf bag.

From an anonymous person:
Matt,
Thanks for speaking some truth about XP. Granted, I'm a cynic. XP strikes me as just the latest silver bullet. Having been made to do pair-programming to a ridiculous level (I joke that I have to eat my Fritos XP-style), your bit about it was thoroughly enjoyed. You hit the nail on the head: programming is meditation. I cannot get my head around a problem when paired, regardless of whether I'm in the driver's seat or not. Thanks for a perfect analogy.

Best Regards and Thanks Once Again,
[Name and email withheld]

p.s. If you decide to reprint anything from this note, please do not reference my name nor e-mail - I guess this makes me a cowardly crank, but my boss has a big name in this business and he will look at your site (and will later gather us for a "two-minutes hate"* session on your behalf).
*a reference to Orwell's "1984" :)

From an Agile Modeling "insider" who wishes to remain anonymous:
My hat's off to you for sticking your neck out in the AM list. IMHO, you did a terrific job skewering XP and exposing it for what it is. You've got everyone in a tizzy (just like you wanted to :^) ). Most of the criticisms of your essay are shallow and emotional or elitist. They have concentrated on attacking the form of your writing (because that's easy to do) and not the content (which is hard to do). A couple of people even ragged (erroneously) about your spelling! I'm sure I don't have to tell you this but keep up the good work and don't be intimidated by the born-again XP mob!

From another anonymous person:
Greetings Matt,
I just wanted to thank you for a sorely-needed belly laugh. . .

...'New, but promising, programmers will apply themselves by learning on their own time. Dumb ones will refuse to learn without "going on a course", or being mothered. You can't polish a turd.'...

How utterly, profoundly true! And delightfully well-stated, I might add. There has been precious little to laugh about between the recent horrible events in my country and my own Horrible, Mean, Terrible, Very Bad, No-Good Managers who, among other sins, euphemistically demand that I 'facilitate knowledge transfer among the junior staff'...Yes, what they are asking in reality is for me to polish their pile of stinky, dumb turds.

I appreciate the new vocabulary. It's so much more accurate!

Thanks:)

Jeremy Hoyland, System Architect at Sun Microsystems Israel, Ltd:
Bravo.
There is a lot of truth in what you say. However I would just like to point out one error in your article (delete now if you wish).

You do not seem to recognise the distinction between functional/acceptance testing, and unit testing. There is a clear delineation here. Unit tests have little or nothing to do with the "software specifications". They test the most trivial of things ad nauseam. If you need to replace a module/unit (say, the hardware it drove has just been replaced by something that costs 0.003 pence less ;) you throw out the the module _and_ALL_its_unit_tests_ too.

In an ideal world the functional tests for the whole system would remain unchanged (BTW, in theory, there is no difference between theory and practice :-)

IMHO the advantages of unit tests are twofold; They allow me to check myself (e.g. that I didn't miss-slip in a new case: before a break; statement) - often to check things that will only occur if the hardware breaks (which can be hard to simulate). They ALSO allow me to check that I haven't inadvertently broken someone ELSE's software - since a good test harness (like jUnit) will let me run all of the UTs in the system, not just my own.

Of course, in an ideally object-oriented world, changing one unit cannot break anything else (see above).

I have found it hard going trying to explain to our test engineers that functional tests are not simply unit tests revamped (they wanted an easy life). Good functional testing begins with the specifications (which I agree you need), makes no assumptions about the system, builds progressively upon previous tests, and tests total system functionality. If someone has come up with a bad algorithm, his unit tests will pass, but the functional tests should fail.

Just my 2p.

Michael C. Daconta - Director, Web & Technology Services, www.mcbrad.com:
Hi Matt,

I really enjoyed your article on the case against XP!
Great JOB!

I had considered writing an article entitled: XP considered harmful (and even started it). Additionally, I refused to do a book on Java XP that my editor wanted me to do.

I will pass on your article to the programmers in my company and wish to again thank you for taking this stand.

Best wishes,

- Mike

 

Mike Hale:

Thank you for a well thought-out and provocative case against XP. To me, XP seems little more than a formalized code & fix (or is it fix & code) RAD method. As you pointed out there are many, many flaws and I love the twisted snake analogy. Very fitting.

One point I'd like to add is how does estimating cost & billing fit in to XP!? Fixed-bids are impossible with XP. This is fine if you bill T&M but otherwise it's just plain suicidal. How does the sales process fit into all this? How do you know you can deliver the solution you're selling if you won't even determine what it is until you are developing?

I could go on and on and make the same case you did, but I'll spare you. You probably said it better than I ever could. I just wanted to drop you a line and say good job!

MikeH

 

<< Back to XP Central
<< Back to Lifecycle

All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright © 1998-2008 Matt Stephens. ALL RIGHTS RESERVED.