In 2002 I gave an invited talk at a Lisp conference in San Francisco. I was scheduled while I was Technical Strategist at a hotshot Lisp-like company founded by Tim Berners-Lee. I gave the talk right after the strategy department was disolved and I was fired with it. (John was in the same department.)
As I remember, it wasn’t well received. (But I was pretty grumpy at the time and considered myself to be not well received by the world in general.) The writing and speaking wasn’t great, and some of the ideas were marginal. But I think a lot of the ideas have stood up pretty well, and I still believe them. I’m going to serialize it here, so that I can reference it in future blogs.
Abstract
The last few years have seen a lot of new language development, but commercial success has eluded many good language companies. A framework for success is presented, in which language systems are recast as open platforms for some class of application. Multi-tier marketing is examined, in which a free or low cost application enlarges the platform’s community, while revenues are produced on an upper-tier product or service. The presentation will be followed by a fishbowl discussion, in which everyone is encouraged to join the conversation.
Introduction
The last few years have seen a lot of new language development, but commercial success has eluded many good language companies. When this conference was organized, I thought I would speak on the technical reasons for the success of Curl for rich Web client applications. Now I have the opportunity to think a bit more clearly about what business strategies work, and how the landscape is changing for language vendors and language systems developers.
Tonight, we’re going to have a fishbowl discussion on this topic. I’ll explain the format in a few minutes. For now I’d like to share some personal observations that I hope will provoke some discussion later. I think these are truths, but there may be other truths that contradict them. You’ll all be able to discuss them at the fishbowl. Please make notes of your comments and truths so that you can hold them until the fishbowl at the end.
I’m going to cover a lot of ground very quickly. Some may be familiar to you, some not. But don’t worry about getting it all. Right now I mostly want to offer up points for discussion.
What Do Buyers Want?
They want to produce applications that meet their specs and their deadlines. That’s pretty hard. The technique that has evolved, by no means perfect, is to rely on known tools and methodologies.
I’ve had the opportunity to study a few job descriptions lately. Monster, Hot Jobs, and so forth. Here’s one for a bank:
Senior Developer:
Required Experience: 4-5 years of programming experience on financial services applications with the following technologies: Interwoven’s TeamSite, Java, EJB, JSP, servlets (J2EE), JavaScript, WebLogic/WebSphere. Excellent communication skills. Ability to work independently as well as in a team environment.
Desired Skills: Knowledge of Visual Café, LDAP, ClearCase, and Netegrity’s SiteMinder
Education: Bachelor’s degree preferred
This listing is for a J2EE house. You can find analogous listings for Microsoft houses, Oracle, etc.
The emphasis is on identifiable skills that can be easily scanned and matched in an automated text search, and easily verified. The idea is that demonstrable experience with these tools will lead to predictable and repeatable performance on projects using the same tools.
An employee who might select and use a more powerful and appropriate mechanism is not an asset, but a liability, because it can lead to project overruns and even failure when interfacing to other parts of the application. Note that a computer science PhD is not sought. Nor is experience with alternate languages, methodologies, or tools. Indeed, quite often, domain experience is not even expected.
This emphasis on experience with a given set of tools is not peculiar to the software industry.
It also occurs in other disciplines, sometimes with catastrophic results. When eleven people were killed and over a hundred injured in the 1996 train crash in Kensington, MD, part of the problem was a poorly designed release mechanism for the passenger car doors. The emergency release was located low, eight feet back into the burning car, past the push of people trying to get out in the dark. My guess from my own engineering experience is that the one who designed that mechanism was hired based on a certain number of years with, say, Autocad release 7 (or some such).
But this is the way it is. Systems buyers accrete products and staff that are known to work together on the class of applications that the organization is developing. Where does that leave us? Where’s the language vendor in this picture? Where does the language guru go?
next: Every Application Architecture Has Plenty of Languages
