LinLog

There was an interesting article over on the Typical Programmer the other day. It consisted of a criticism of an anti-agile development paper entitled Agile Methods & Other Fairy Tales, by David Longstreet. While the criticism was interesting in its own right, I found it even more-so after reading the actual paper.

The main criticism the Typical Programmer leveled against the paper was that it was attacking a straw man. Specifically, he claims that many of the practices Longstreet describes are not actually agile, but simply broken. They just look agile because they don't involve much in the way of design, documentation, and so forth. Real agile methods, however, do not scorn those things when they are necessary.

I don't claim to be an expert on agile methods. However, I found Longstreet's paper to be good in some places. It certainly wasn't as intellectually bankrupt as the critique would lead us to believe.

Thinking about all this raised a few questions in my mind.
1) Couldn't the same complaint be leveled at the agile people? That is, might one not claim that they're not reacting against waterfall-style methods, but rather a caricature of them? After all, you can dress some broken methods up as waterfall just as easily as you can dress others up as agile.
2) Just what are real agile methods anyways? How do you differentiate it from "fake" agile? Viewed from the outside, it seems like agile methods could very easily be mistaken for cowboy coding. How do you decide where the line is?
3) Is it just my imagination, or do agile methods get less controversial every time I read about them? For instance, I remember when everyone was talking about the pair programming advocated by eXtreme Programming. Now, it seems like nobody cares about that anymore. (Actually,it almost seems like people have come to a silent agreement that it was kind of a silly idea.) These days, I read about the de-emphasis on documentation and other non-code artifacts. But then, when pressed, the agile people say they're only against the useless documentation.
4) Isn't "requires producing useless documentation" almost the definition of a broken development method? Yeah, sometimes it's demanded by the customer, but in other situations, does anyone ever think this is a good idea? It seems to me that if you're writing design documents that you never use, then you're missing the whole point of writing them in the first place.

Brain dump completed. Time to do some more reading on agile methods.