Of Strawmen and XP

I stumbled across an anti-XP paper on the ObjectView site. I decided to take a look, and see what the author's beef was. I'm a little surprised at the sheer intellectual dishonesty involved here. For instance, the authors state at the beginning:

To start with, the complete title (which is "XP Refactored - The Case Against Extreme Programming") will give you an idea of what Matt and I are doing. By way of background, I got engaged in the XP debate originally on OTUG (the Object Technology User Group), mostly with Bob Martin and Ron Jeffries a few years ago (this culminated in quite an intense discussion about the Chrysler C3 project, and whether its cancellation meant success (as they claimed) or failure (as it seemed to many of us). Subsequently I've made a few attempts at satirical humor that have been pretty well received, notably "Alice in Use Case Land", which was a keynote speech I gave at UML World and recently repeated at the Rational User Conference, "Fragile Methods" which was a talk I gave at SD West, "Emperor's New Code", and then my son Rob and I have a lot of fun rewriting old Beatles songs, which we've compiled into "Songs of the Extremos."

Well let's just start with that, shall we? Based on what I've read on the c2 Wiki, the project died for the same reason that many projects die - politics. In particular:

Near as I can tell the fundamental problem was that the GoldOwner and GoalDonor weren't the same. The customer feeding stories to the team didn't care about the same things as the managers evaluating the team's performance. This is bad, and we know it's bad, but it was masked early because we happened to have a customer who was precisely aligned with the IT managers. The new customers who came on wanted tweaks to the existing system more than they wanted to turn off the next mainframe payroll system. IT management wanted to turn off the next mainframe payroll system. Game over.

That's a clear political problem. And yet the leading premise of the authors of this paper is that - since C3 failed, XP failed - these guys are big fans of some Iconix modifications to the RUP process. So by their leading argument, if any RUP project has ever died due to politics, RUP is a failure? Is this the kind of argument they want to make?

Let's move on. Their next strategic argument is the setting up of a strawman. In reference to "The simplest thing that could possibly work":

Well, there are many variations on this theme. KISS (Keep It Simple, Stupid) is one of them. And keeping it simple is, of course, a good idea in most cases. But let's examine the phrase "the simplest thing that could possibly work". Think carefully about what this means. This phrase goes beyond normal "keep it simple" advice. We do not build generality into the system in expectation of future requirements. We build the simplest objects that can support the feature we're working on right now. This is a very very different idea from just "keeping it simple". This says "don't think ahead about other requirements, just slap some code together for what you're building RIGHT NOW". This advice, in the hands of most programmers that I've ever met (and I earned my living writing code for about 15 years), can prove to be incredibly dangerous. What the Extemos ask you to believe is that "constant refactoring after programming" (do your own acronym) makes that all OK. It's OK to hack stuff together with rubber bands, bubblegum, and scotch tape today because you're going to refactor it tomorrow anyway. Uh-uh. Not for me.

You see that? YAGNI means, don't build more than you need to, since your guesses are unlikely to match future needs. They morph this into "hack it any old way and refactor later". It doesn't mean that. In fact, they know it doesn't mean that - either that, or they simply made wild assumptions a long time ago, and have stuck to them in order to justify their arguments. XP isn't about hacking - in a true Test Driven Development set up, hacking is the last thing that will occur. So again, these guys have translated a part of XP into something it isn't, and argued against that fake problem. The interviewer should not have let them get away with that.

Later, they complain that early deliverables results in the project going into maintenance at a very early stage. so what? BottomFeeder was delivered in its 1.0 incarnation at a point where these folks would have said it was not ready. The advantage of that was early feedback from real users who could raise real issues with what we thought were good ideas. We learned a lot that way, and have iterated to a much better product over time. It hasn't stopped us from big changes either - which is one of the "problems" they say will occur - entire subsystems - including the feed persistence mechanism - have been changed over completely more than once. It sounds to me like these guys have had the luxury of working on projects that are very stable, and where requirements change slowly - if at all. That's not the world most of us developers live in.

But wait, here's another whopper:

"My big issue with XP's approach is that pair programming is used as an excuse for not doing upfront design. That's completely bogus, in my opinion"

What's completely bogus is this assertion. Pair programming works from the "two heads are better than one" mindset, not at all from this silly statement. He goes on to make a whole lot of claims about how pair programming wouldn't work, based on two examples. Argument by anecdote, always a great way to build a strawman. But wait, there's more!

Actually, a nice aspect of XP is that the individuals get to sign up for the tasks that interest them the most in each increment, so their natural role in the team really does emerge. I would recommend doing that in any project, XP or otherwise - letting people identify the things that interest them the most. People are much more highly motivated when they are good at what they are doing, hence more productive. Of course you have to draw the line somewhere though: there are always "chores" that somebody just needs to knuckle down with and get done. And an added danger is that in a roomful of programmers, no one ants to do design, or test what they've written, or write things down. They just want to get coding: everything's a prototype, nothing is customer-facing, unless they are told otherwise. Sometimes you need someone in a position of higher authority (a team leader, say) to make sure the not-so-fun stuff gets done too. Otherwise, it's like having a house full of kids who are allowed to watch TV and eat ice-cream all day, but the washing-up never gets done.

I love his casual assertion that in XP, "chores" like testing won't get done. He's either never read anything about XP, or he's back to making wild strawmen up to combat. Either way, it's laughable. Test First is perhaps the most important tenet of XP. But it's so much easier to invent strawmen than to actually have a cohesive argument...

Bah