I really am a fan of Agile development, and smart people are abound in any methodology camp I attend (mailing lists and such). But sometimes, *plenty of sometimes*, instead of talking about details, and "how" to do things, people start getting very philosophical about it. What do I mean by that? Well, there are several signs that things are going astray:
- People start to argue about the smallest insignificant things, such as naming for various practices, what does the XYZ acronym really mean, how long is an X amount of time *really* supposed to mean, or was it just an example of a more elaborate part of the author's idea for the methodology. (for example, trying to find an acronym that means the opposite of BDUF)
- Someone would go into the forum or mailing list, and ask a simple question such as "We're trying to do small iterations but management won't let us" and in response they would get stuff like "Leave your Job" or "If they don't let you do all of it, you might as well forget it" instead of something that actually helps people out
I'm more of a pragmatist. You'd think that people that implement all this stuff would have far fewer time to sit down and simply chit chat with the whole world about whether an XP Oath is worth taking all over again (even if you decided that the answer is "yes", can you convince anyone but the 50 people who actually try to read the whole thread?)
I don't like people who simply talk too much about something until it starts to live in a different dimension (an old saying about Buddhism I think it was, goes "Look at something until it becomes boring. Continue to look at it until it becomes interesting again") once it starts to get into the "But what does "Energized Work" really mean?" kinda stuff, I start to lose my patience. i see no value to real life there. I would never use that term because I would use the term best suited to describe to people what I want them to do. Just like I wouldn't use the term "pair programming" in some companies, but still encourage people to "try and solve this problem together" to achieve the same target. Useless discussion.
In the same way, while I really do like the idea of software architecture, and do believe in clear architectural practices of various sorts, I can't really stand any long winded discussion about things that are so high up in the sky, that they don't even matter to any development organization I would ever encounter. Take any highly acclaimed book-architect(the kind who write architecture and methodology books for a living) and ask them to help design the smallest piece of software, something simple. Would they over-architect it? Assuming they follow all their own prescriptions, you bet. Now, have them architect a very complex system - would they over-architect that as well? Assuming they follow all their own prescriptions - probably! and they would probably take much longer too. Oh, and take more money of course. Why? because people who speak in terms of "We are all building part of one large software the whole world is using" will always always only be able to architect systems that fit into the gigantic terms that they use. They have no use or interest in smaller scale, uninteresting, simple systems. Like billing, banking and so on.
I'm not against architects - I'm against all the fluff that surrounds all the "high level" discussion about architecture. People have been discussing the term "Service Orientation" for a couple of years now. The only thing this has brought us is only more discussion. Artifacts for a Service Oriented world are just now starting to arrive and what you'll find is that everything is pretty much what is used to be, if you ever tried to build a large distributed system. Things only got easier, but nothing has fundamentally changed. Actually -some things changed. Many people spoke for a lot of hours about concepts that only 2% of the developer population would ever really understand. In the end, the lowest common denominator still rules. Most systems are still built and will be built in a client-server fashion. *some* systems will be services, but how many systems will use "service conversations" and Service discovery mechanisms?
Take UML - that amazingly rich language which allows you to explain systems in many many ways. But most people would not have the slightest concept of how to use all the facets of UML other than drawing some squares and straw man on the white board and connect the dots, because that's what really matters. Yet very smart people have slaved over this standard for years, talking in a very high lever about earth shattering ideas. But I've been drawing squares on the white board for as long as I can remember, and before I ever read one design book. Some of the people who invented UML actually work at MS now, helping to create Microsoft's version of a system design tool - you can call it a stripped down UML with specific names for squares and lines, but no other types of diagrams (software factories). The lowers denominator one that contest too.
The lowest denominator will win the Service oriented architecture contest in just the same way. Architecture principals, the simples ones, will be used. All the others will be known by 5% of the dev population and never really used (which is why I think COM+ was not as widely used as it should have been - the explanations and the architecture was a little too high up there for many people who had more important things to do like creating a system instead of reading a full book to learn that they can save lots and lots of code - what a shame).
I also think the lowest common denominator will win the Methodology Contest. People will speak high and mighty into deep, very deep methodological issues and concepts. But in the end, only the simplest things will survive and ever be aired in public. The others just won't last because the dev community will only listen to what's easy to consume.
In short, when I hear people start to go "deep down" into things that don't really mean anything in the real world. I know I can turn off the old conversation radar - it's just water passing down the stream, not rocks.