Thursday, September 29, 2005

Is Extreme Programming an Overreaction? (Part 1)

I've been doing a lot of research and thinking about methodology recently. I also went to SD East this week (great show, great conference) where I was overloaded by Agile this and Extreme that. I guess I was lucky though. I joked to one speaker that I figured I'd made a mistake by leaving out the word "Agile" from my presentation title since it was in practically every other presentation title. He shrugged and said "it seems less here than at other conferences." I can only imagine which conference he recently attended. It must have been called something like "Going Beyond Extreme Programming" or "Lighting Methods for Legacy Agile Developers".

I've read up on Agile methods and Extreme Programming, read articles, talked with prospects and customers about it, and used many of the ideas over the years. For the most part I had heard about those ideas or learned about them prior to having heard of either "Agile" or XP, so I never really thought of myself as an Agile person or an XP person.

I also heard about pair programming, but outside of frequent code reviews, haven't actually done true pair programming. It doesn't strike me as my cup of tea.

In any case, I guess I had subconsciously formed an opinion about Agile methods and then began filtering out new information. After all, I "knew" what it was, so now I could think about other things.

But then I did some more in-depth research on modern methodologies in general, spent some time at a customer that is "going Agile" and followed that up with a week at SD East. I was forced to realize that I had not fully appreciated what it meant to be "Agile."

I can't help but thinking: "is this an overreaction to something?" I've heard things like "but isn't extra training contrary to the manifesto that says 'the only measure of success is creating working code?'" and "keep track of the project with a stack of 3x5 cards." You might say that I'm the one that is overreacting, that I'm only picking up on "the extremes." I don't generally react so strongly to an extreme comment here and there, so I'm pretty sure it is the steady drumbeat that I'm reacting to. By the way, how do you Google a stack of 3x5 cards?

My gut tells me that Agile is a programmer-centric reaction to a feeling that there is too much bureacracy keeping the programmer down; mangement is too heavy-handed, and the development tool stack is too hard to use. If only the programmers were in charge, everything would be better. And to top it all off, the guiding principles are set out in a Manifesto. I agree with some of the principles in the Manifesto, but to me it seems to go a bit too far.

For instance, take the principal that "Working software is the primary measure of progress." That seems far too programmer-centric to me. I agree, there's nothing quite like the rush of seeing a newly implemented feature in action, or the satisfaction of squashing a clever bug. I could spend all day implementing cool features and squashing bugs. But outside of personal hobbies and coursework, isn't the point of developing software to maximize customer happiness and new customer acquisition? At the end of the day, isn't software development a tool for achieving success in business?

Now that I have your attention, stay tuned for Part 2!

1 comment:

Anonymous said...

Damon, you've confused the metric with what's being measured.

Agile developers don't simply work on whatever they feel like (in contrast to open source developers, for example). Agile developers work on activities that provide the most value to the customer, in the order the customer specifies.

A consistent flow of completed, virtually bug-free activities is the measure of progress.