Okay, I've got to admit when I first heard of eXtreme Programming, I was drawn to the radical nature of it. Then I discovered one of the key components is that developers work by pairing up two to a single computer. What? That sounds like a school lab without enough funding to provide computers for each student. Is that an advancement? Besides, how could that approach jibe with the fiercely independent motif of the hacker/programmer? Do people actually like this process? Would they produce under such a system?

Once I started thinking about the paired programming thing, I started to realize there may be some real benefits to the approach. It certainly would reduce the temptation to get distracted checking personal email or getting off-task since it would require both programmers to be similarly unmotivated. The other obvious advantage is the old saw about two heads being better than one. Techniques and approaches can be discussed as work is being done, plus you double your chances of catching obvious mistakes as you go.

Of course, paired programming is only one component of eXtreme Programming- and not even a mandatory one. I later discovered that XP (as its practitioners call it, apparently unconcerned about clashes with MicroSoft's ubiquitous OS with the same call letters) is one implementation of a larger methodology referred to as Agile. Who wouldn't like to be associated with "agility"? Sign me up, right? The process not only allows and encourages agile production, but is agile itself- able to change and adapt as necessary. Well, let's take a look at some of the over-arching philosophies in play here.

Some of the tenets of the Agile process are hard to argue against. 1) Deliver working, bug-free code early and often. Okay, I'm all for that. 2) Involve the user throughout the development process. Now there's a concept I can get behind! 3) No overtime ... wait a minute. No overtime? How can you produce great software without long weekend and late night sessions fueled by cola and pizza?

This Agile stuff clearly needs some looking into. There is a lot to it and there are plenty of resources out there if you want to learn more about it. I can only share my observations and opinions here.

More reference links coming here soon!

Agile Manifesto

Crystal Clear, by Alistair Cockburn

Agile Modeling, by Scott Ambler

Accelerating Process Improvement Using Agile Techniques, by Deb Jacobs (little pricey but excellent)