Steve Jones has a long piece explaining why he considers a static, contract-driven, fix-as-much-as-possible-up-front approach superior to a dynamic environment. (It’s hard to quote a single statement, so go and read it, then come back).
In fact I agree with Steve to a large degree — e.g. I don’t claim that REST is simpler than WS-*, or that Ruby is simpler than Java. In fact I believe that architecting systems and developing software is hard, really, really hard in fact — but this is true no matter what technology you use. The first large projects I did were built in C++ — and anyone who ever tried to build large-scale software in C++ knows how easy it is to get things wrong, and how much below-average developers struggle with memory management, implicit type conversions, construction of temporary objects, and a million of other issues. And I definitely remember how relieved I was when Java came along and a whole set of problems disappeared for many developers I worked with … or so I used to believe.
I don’t have this view anymore. My personal experience is that bad developers will produce bad code in any language, and more rigidity will not magically make them build something better. In fact, the opposite may be true — because some mistakes are less easy to make, it might take much longer to “discover opportunities for skill improvement” (just to introduce a nice corporate euphemism). The belief that forcing developers to use a statically typed language will prevent them from making mistakes in any significant manner is not justified IMO, just as much as forcing a Rational Unified Process in all its glory will not prevent your projects from failing.
Going back to the C++ analogy (pick C if you prefer): Those who are able to understand manual memory management and pointer arithmetics will benefit from Java and will likely build better programs. Those who lack the strange gene required to understand pointers will be able to hide behind Java for a while — but ultimately their code will explode, too, just in different ways.