There are several good comments in this thread about agile methodologies. Personally, I think that hype or not, it fits with the perlish notion of a good programmer combining laziness, impatience, and hubris. Echos of it also appear in Pragmatic Programming. And Extreme Perl is a great reference for how XP fits together nicely with Perl.

In terms of understanding the similarities and differences between "agile" and "iterative" development (and how they both differ from waterfall development), I highly recommend the book Agile and Iterative Development: A Manager's Guide, by Craig Larman. It written for managers, not for programmers, so conveys concepts and motivations more than specific processes, though it does give an overview of several of the most common flavors of agile/iterative development. Importantly, it points out several of the pitfalls that people encounter attempting agile/iterative approaches. (For example, RUP is supposed to be an iterative process, with timeboxed iterations of a few weeks, not a documentation framework for waterfall design as it's so often encountered in large organizations.) It has great references and citations, too, for following up any of the topics covered. It's well worth picking up if you're even curious about agile development.

What the an above poster called "head's down programming" is simply recognizing a "hype machine", and often elitists will make fun of people that don't buy their particular religion -- calling them dumb, "head's down programmers" or "grunts" or what have you -- often these are the best practical and creative people you have. Why? They think for themselves. THIS is what you want. The best "head's up" programmers are ones that don't need overpaid consultants dictating new methods to them. They can figure out processes and invent processes on their own. That's me.

Just to clarify - since my intent was not to offend.

By "heads down programmer" I refer not a "grunt" or any other such negative euphamism. What I refer to rather is a programmer writing code in a solo environment to the exclusion of all else. If that's what you do - my advice is to reinvent yourself before you get outsourced.

Are your eyes only on the code or are they on the overall goals of the project?

Is your focus to write the best code possible for the job or merely to keep your seat so you can receive a paycheck next week?

The criticism is "Iterative Development w/ a bit more spin" and you're absolutely correct. However without that "spin"/"hype"/documented research you're NOT going to sell the idea to upper management & therefore they're going to impose the Waterfall method on you. Why? Because it works better for business concerns. Be it RUP or XP or whatever methodology/"Hype" you buy into - YES it's common sense coding practices - rendered in the form of a methodology.

So - to recap - we're all for common sense, and we're all for the priciples we preach. But we're against solidifying on a "methodology" because..... we don't like being told what to do?

And for every brilliant programmer like "anonymous monk" how much dead wood makes it's way into the department? How do you keep them in line?

What happens when you get a promotion & you have to manage programmers instead of writing code? Do you teach them the best practices you've learned or do you trust in their artisitic and creative brilliance to spontaneously know what it took you years of experience to learn?

ANY development method tries to organize your approach to development. They get you to think about a problem up front instead of later. They get you to address & mitigate risks up front instead of later when they're more expensive.

And as for the original comment about Resumes... YES if you've worked with RUP or XP put it on your resume. It means that much less training you'll need to fit into a new job where they do such things. It means you know how to work with a team and be organized. Is that enough to get you hired? No. Can it hurt? No.



Wait! This isn't a Parachute, this is a Backpack!

Of course. I agree with two points that you *almost* made... =)

One is: that any methodology exists in order to keep stupid people from hurting themselves or hurting the company. Smart people are often rightly exempt from the most rigid implementation of whatever process is in place. (Of course, even smart people make mistakes. CPANTS and kwalitee implement a lot of agile ideas.)

The other point is: I wouldn't use agile methods to build, say, a cruise missile. Or an air-traffic control system. Or a spaceship. There are any number of applications that demand the discipline and documentation that agile methodologies lack.