This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Smalltalk and Productivity Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general. Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

I've posted quite a bit on why I think Smalltalk is more powerful than many of the competing solutions - now I'm going to toss a few numbers around. One of the fascinating things about the software field is the relative dearth of hard data. Even when there is data, however, many people are more than happy to rationalize that data away. Take this post from 2002, for instance - I can paraphrase the analyst viewpoint this way:

Never mind the fact that our research says that following the mainstream of development will yield dramatically higher failure rates. Being mainstream is all that matters!

The amazing thing is that companies pay huge sums of cash to have unqualified people advise them that way. It's hardly limited to analysts though. Ask a developer how hard it is to learn a new language (software language, that is). I've yet to find one that will say it's a significant hurdle. Now, go recommend to a development manager that project X should use Smalltalk (or some other niche language, for that matter). Suddenly the eyes glaze over - "but where will I find staff?" Never mind that his entire existing staff will tell him that learning a new development language is not a real problem.

But wait - it all extends down to developers as well. I've been pointing to this post (which has been updated here in the past couple of days). "Source code not in a directory tree? Syntax that doesn't look just like C? Heresy!". There are plenty of developers that are stopped cold if the syntax isn't sufficiently C-like, or if they have to do anything differently than the way things have "always been done" (I seem to recall the old auto industry being run clean over by overseas competition - partly as a result of hidebound practices. But nah, that would never happen in software - offshoring's a myth, right?). Well, even actual data doesn't get through the wall of rationalization.

SPR still has the data compiled by Capers Jones on language levels, error rates, and lines of code per function point. The data is instructive, if a little dated (1999). C# wasn't out then, but - I would have to place C# within the same basket as Java. Here's the relevant snippets from their data:

Ponder that for a moment (Function Points are defined here). With a little arithmetic, you find that Smalltalk is nearly 2.5 times as productive as Java. You'll immediately run across two objections to this (try making these points in comp.object to see what I mean):

• Function Points are meaningless
• You'll get more errors in Smalltalk due to the lack of manifest (declared) typing

Well, the first point is nothing but a rejection of the data by assertion. This is research that was done over the course of many years; if people want to object to it, they can point to conflicting research. I've yet to see any such argument being made. The second point is commonly made against Smalltalk (and other dynamic languages). However, there are some other bits of research from the SPR documents in this area - it turns out that they measured error rates per function point:

So much for that. The arguments you'll hear at this point hold as much weight as those against Function Point measurement - the assertion will be made that it's all irrelevant, without any attempt to point to research that shows otherwise.

The bottom line is, this is the data we have, and it points in a particular direction. Do analysts pay it any heed? No, the best they can do is count the number of developers and declare winners (they seem to think that this is all Nielson ratings). Project Managers? No, they quiver in fear of finding developers (regardless of what real developers would tell them about ease of learning). Developers? No, they have a magic faith in C style syntax and declared types (It's what we've always done, don't bother us, we refuse to look at contradictory data). This is a large part of the reason that I run this block - it's an uphill battle, but I have to keep pushing the rock up the blasted hill :)