Any kind of "methodology" is aimed at improving the predictability of results expected from a group of average coders. Thus it's no surprise that "large client"

Any kind of "methodology" is aimed at improving the predictability of results expected from a group of average coders. Thus it's no surprise that "large client" appears in the first paragraph of his blog post. In reality, software engineering is more like an art, and each project calls for a somewhat unique approach, unique style. There is a lot to be said about general sense of style and beauty when it comes to programming. Imagine Leonardo "going Agile" on Mona Lisa in order to speed up the process. Of course there are always armies of copycat CRUD projects that have nothing unique about them. It only proves my point of average quality of "agile programmers" because good engineers aren't interested in CRUD work. Ruby-on-Rails is an awesome example of this: one good programmer did all necessary thinking for you. It is perfectly possible to deliver a "typical Rails" site without even caring for learning Ruby. A good methodology done right allows code monkeys with surprisingly low skill level to be productive (which is, of course, not a bad thing). Rails is agile-carved-in-stone approach that forces you to stay on track and punishes from levitating from it, I guess this is where word "rails" comes from. This drives many MBAs nuts: none of those dog-training managerial books filled with pompous common sense seem to work when applied to software: good programmers simply don't respond to "positive reinforcement" and average programmers produce average results no matter what. All those "methodologies" allow managers to get average results reliably regardless of quality of talent at their disposal.