This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

You're Not Sharp Enough for that Knife

Stefan Tilkov,

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.

On May 14, 2007 4:31 PM, Steve Jones said:

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.

On May 14, 2007 7:13 PM, Bill de hOra said:

“My point is more about the “average” developers and of course the people in support”

Death on the roads is not solved by adding more traffic lights.

“developers produced many less bugs in the “strong” language than they did in the “weak” one”

Data please. My understanding is that the biggest predictor of defect density is line count which doesn’t seem to mesh well with that observation (tho in truth I suspect defect density is strongly correlated to overtime and bad requirements)