Software development selections
I've been thinking about this post by Joel Spolsky again - I posted on it last night before I went to bed, but I didn't really go into the topic that deeply. Joel asserted that developers have tried Lisp (the same argument extends to Smalltalk) and rejected it in favor of things like VB, C++, C#, and Java. This is an argument I've heard many, many times. The problem is, it's completely bogus. First off, most developers haven't actually tried (insert niche system here). One of a small number objections come up, either from developers or from management:
- We won't be able to find any (blah) programmers!
- That technology is very old (never mind that the libraries are up to date)
- I would rather work in (insert mainstream language here), so that I can stay marketable
Notice how none of these are actual technical arguments. The first two would be reasonable management issues if they had validity, but they don't. First off, go find a developer. Ask them how many software development languages they know, and then ask how hard they find learning a new one. Heck, if newness alone was a barrier, then neither Java or C# ever would have taken off.
The objection is often this: "If we build a Smalltalk application, and our developers leave, what then?" Well heck, what if you build a Java application, and your developers leave? Sure, there are more people who know Java - but that's not the hard part. How many developers are you going to find who know and understand your business domain? If you had a choice between hiring:
- Someone who knows your problem domain, but doesn't know the implementation language
- Someone who knows the implementation language, but doesn't know the problem domain
Which one would you hire? The better answer would be the first person - learning the new language will take a lot less effort than learning the problem domain. Many IT managers don't actually believe that, even if they say it - that's clear from the way they hire and the way they decide on implementations and rewrites. It's equally clear that business staff (implicitly) think differently - the knowledge staff that handles business issues is typically not full of candidates for outsourcing.
Let's go back to the other part of Joel's assertion - that "millions" of developers have tried (Lisp, Smalltalk) and rejected them. That's just silly. Sun claims that there are 3 million Java developers. Most people think that VB has wider penetration, and I'd guess that C is on the order of Java. Then there are niche languages like Smalltalk and Lisp - millions of developers have tried them and rejected them? I don't know about IBM's VAST numbers, but I know that we get an average of 1000 or so people downloading VW and OST Non-Commercial per month. Even if every one of those people actually took a serious look at the products, that's in the low tens of thousands per year (and some of these are repeats - people picking up newer revs). Back in its heyday (pre-Digitalk merger), ParcPlace was a $40 million dollar firm, and I recall that we had estimates of actual end developers in the low tens of thousands. Digitalk was something like a $10 million dollar outfit, but likely had at least as many (possibly more) actual users. VAST was bigger, but not significantly so. Those numbers went down in the late nineties, and have now started to go back up again. Does that qualify as "millions" of people having tried Smalltalk and rejected it?
Like many other things, software development is a popularity contest. There is perceived safety in numbers, and the C language family has become that "safe" haven. This has nothing to do with quality or productivity - it has to do with the fact that C was a good choice for development early on (given the state of the art in processors, disk and memory) - and that advantage built up higher through inertia and the creation of a large "installed base" of people who knew the language. C , Java, and C# benefit from this familiarity, and VB benefits from the widespread early deployment of Basic on PCs and University systems.
That's not a rejection of Smalltalk or Lisp, at least not in the way Joel implied. It shows that the early "winners" in the language derby gained a large advantage in terms of mainstream adoption. It says nothing about how hard it would be to use a niche language, even though many people (especially IT project managers) read it that way. As I said above, training a new developer in Smalltalk is a whole lot easier than training them in your problem domain. Having developers learn Smalltalk is not a hard thing - just ask them. Bottom line - if you make the statement "Yes, Smalltalk is more productive, but..." - just eliminate the latter half of the statement.


Comments
Old dogs, New tricks
[Take the First Step] February 27, 2004 16:38:09.080
Trackback from Take the First Step
Old dogs, New tricks
James Robertson is taking on the curly brace nimby crew in support of Smalltalk and lisp. I wish him luck – our inability to expand our horizons is a major factor in slowing the evolution of software development. But he's got a tough row to hoe ahead of him.
It's hard to learn a new programming paradigm. Twenty years ago, I knew good Fortran programmers unable to transition to C because they couldn't get a good handle on pass by value vs pass by reference. Ten years ago, I knew good C programmers unable to transition to C because they couldn't get a good handle on objects. I'm willing to bet that there are good Java and C# programmers out there who will stumble over a transition to Smalltalk. And I'm sure that all of them would deny that there would be a problem before the fact.
There is a risk in adopting Smalltalk. And I think that Smalltalk would be better served by increasing the developer pool than by downplaying that risk. It's not enough to make the language freely available. Provide tools and incentives to actually learn it.
The real question is whether it would be too little, too late? Would a Geoffrey Moore Crossing the Chasm marketing push still work? If you could somehow create a critical mass of people with both Smalltalk and domain skills, then you could really make some inroads.
...Software development selections
[Alex Peake] February 29, 2004 17:00:31.486
I believe a Crossing the Chasm marketing play could still work for Smalltalk (and even Scheme/Lisp). The greatest impediment, IMHO, is the vendors themselves.
If you take Cincom VisualWorks, which IMHO has the best chance of them all, you find that they do not buy Geoffrey Moore's theory, or at least do not appear to act as if they do?