Well I guess I'll have to go ahead & disagree with you.

It would seem that programmers who have had the benefit of coding in a vacuum or in small teams at best tend to chafe against structure. It's tough to be a code-cowboy when you have to face rigorous peer code review.

What confounds me is how poorly received new development methodologies are when the point of them is to solve long-standing problems.

I'd say the most relevant thing about Agile development processes is that they embrace an iterative development cycle and poo-poo the traditional waterfall method.

This offers an opportunity for an institutional method to be introduced to reduce the effects of feature-creep. By developing in iterations you can hit the target that keeps moving and not have to look like you slipped your deadline each time the rug gets pulled out from under you becasue someone changed the project specification. It actually holds those people making the changes accountable for the impact on the deadline & the bottom line. How is this not a Good Thing?

What the processes DON'T do is to effect your coding style. They don't tell you how to think to solve problems, they don't tell you how to achitect your code and they don't assign you a serial number etched into your forehead after they shave your head...

Agile methodologies are more about Project Management than about code. While I agree that it is somewhat untastefully policitcal what you have mentioned with respect to forcing you to learn on your own time with the implied threat of losing your job (or at least access to the sexy projects) - I also will point out that as a developer you need to do that anyway. You shouldn't be waiting for someone to prod you into learning about new things. You should actively search them out yourself. Our industry changes constantly & to stagnate is to die. IMHO we simply no longer have the luxury of being a "heads-down-programmer." You need to constantly reinvent yourself.

I think that you misunderstood my intent. I have nothing against agile development practices at all. I just argue that they are not a skill. I did a lot of the stuff that the agile guys extol long before it was sexy.

thor

Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come

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.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

That, in itself, is just Iterative Development w/ a bit more spin. Not saying such concepts are bad, but all concepts have situations when they should and should not be applied. Too much of a good thing is almost always bad -- the best programmers learn from many sources

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.

Heh, pretty soon they'll be saying all programmers are required to include 15 pieces of flair in their programs, minimum. Don't you want to express yourself??

I think that agile programming is great and all... but ... I don't see it as a skill that one can put on a resume.

Why not? People put things like "works well with others" on resumes, or other somewhat vauge and intangible attributes... What's wrong with something like "Experience with agile development methods, including management of rapid release iterations and close customer collaboration", or whatever agile methods you manage to pick up?

Your resume shouldn't just list the programming languages that you know; it should also include the supporting skills and "ways of working" that you possess.

Yesterday, an e-mail went out to our product development group saying that there was going to be a webcast by one of the agile programming pundits today and that we'd be tuning in in one of the conference rooms. The e-mail went on to further state that time taken to watch this webcast would be your own time (as opposed to company time).

The company is sending an unintentional, but valuable signal about what level of support they'll give to Agile practices: A little, but only little. I rather suspect they think they can get something for nothing. Still, it's better than their being hostile about it.

I think that agile programming is great and all...but come on! What does one have to know beforehand to do it?

It helps to understand the economic model and the thinking and philosophy behind the practices, so that in a crunch you'll make good decisions.

I think that a more wide-spread acceptance of the usefulness of unit testing is the most important trend in software development in the last decade.

This is because it pinpoints one of the biggest problems we have; change is expensive and so is poor quality.

I know unit tests isn't "agile" per se, but it's at the core of most agile methods.

/J

Holy Grail?

Exactly my point. I find that people are either indifferent towards it or are zealots expounding on the virtues that agile has to offer. I hate zealots of any kind. To pre-pick a solution without knowing anything about a given problem is ridiculous. Granted, there are lots of tools that are well suited towards lots of jobs, but there is no one tool (or methodology) that solves all problems.

thor

Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come