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.
Stefan,
There are bad developers and they should simply just be shot, cruel but I feel fair. My point is more about the “average” developers and of course the people in support. Bad developers are people who use “==” on strings, average developers are the people who struggle with multi-threading and async and don’t quite get the idea of threadsafe and need their code properly reviewed.
Its sort of “langauages don’t kill projects, people do” but I have to say that, as with guns, the languages certainly help. My experience using very static language such as Ada and Eiffel (in both cases where developers were doing C as well) was that the same developers produced many less bugs in the “strong” language than they did in the “weak” one.
So while for the bad there is no hope, for the average it makes a massive difference.