~ryanlowe/blog: The XP Leaps

The XP Leaps

It's hard to believe in extreme programming (XP) because it requires several leaps of faith at once. When you see how these leaps complement each other and work together you'll realise the total benefit of the process. Until then the individual counter-intuitive leaps won't seem safe.

The book that bridged the leap for me was Kent Beck's Extreme Programming Explained. Thanks Andrew.

Here are a few of these leaps (with doubts) so you can recognize them:

- Using developer time to write tests: test driven development
(shouldn't developers be writing code? why waste their time?)

- Very little artifacts
(what if my programmers leave the team?)

- Enabling refactoring
(how can I make UML diagrams if the architecture keeps changing?)

- Pair programming
(wouldn't they work twice as fast on their own?)

- You Aren't Gonna Need It (YAGNI)
(shouldn't I make my architecture flexible to be ready for the future?)

- All of the unit tests and customer acceptance tests run 100% all the time
(impossible!)

- No code ownership
(if something goes wrong, who do I blame?)

- Regular integration and automatic test runs
(that seems like a lot of setup to me!)

- Customer on site
(but they'll see the man behind the curtain!)

- Release early and often
(the customer will fire us because we're showing them unfinished code!)

There is no singular argument to these doubts. I'll admit that learning XP is sometimes an exercise in futility ... you have to unlearn a lot and it takes a while to digest all of the principles and recognize their interconnections. There is no silver bullet. All it takes is an open mind and a desire to listen to your customer's and bring them into the process.

Posted at April 05, 2004 at 06:40 PM EST
Last updated April 05, 2004 at 06:40 PM EST

Comments

Just a thought. You commented on having to unlearn a lot to grasp the utility of XP. So it may be picked up "easier" by a freshman developer. Can you think of any problems a XP developer would have transitioning to another technique or would they just pick up the aspects of development that would normally have to be unlearned?

» Posted by: James at April 5, 2004 10:43 PM

- Very little artifacts
(what if my programmers leave the team?)

The notion that XP has very few artifacts is more of a by-product of the following

- Deliver working software
- Only do what benefits the customer

So, in XP you do not need to feel guilty about not having a lot of documentation. In the same breath you should also be okay with wanting documentation - if you feel is will help you work [faster / better / etc] which will in turn benefit the customer. Finally, let's get back to not feeling guilty about maintain those once useful documents.

» Posted by: aforward at April 6, 2004 03:59 PM

Documentation is more of the customer's call I think. If they want it, you produce it for a snapshot of time (see previous rant on XP Artifacts). Otherwise, maintaining it just slows you down.

If you feel the need to document things, you probably aren't communicating with your team enough, right? Why else do you need a document? If your team is dispersed, that's a little different ... but I'm talking about "pure" XP here where everyone is in the same room not seperated by cubicle walls.

» Posted by: Ryan at April 6, 2004 07:55 PM

Good posts on XP. I've started looking into XP and TDD in the past month or so. And when I started reading Kent's book I had many of the same doubts as you posted. Still not 100% sure about the _whole_ XP concept (I still have a lot of stuff to unlearn), but it sure looks nice when NUnit lights up all green.

» Posted by: bliz at April 12, 2004 12:44 AM