[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Industry versus academia
On 22 February 2003, Sundar Narasimhan presumably wrote:
> Well.. when you water it down to be non-controversial that statement
> becomes almost content-free.. for me at least.
Your objection to the thread seems to have been that some arrogant
persons on this list were asserting that average programmers are
dumb. None of us wrote that.
I did, however, write about mediocre programmers, and I do not
apologize for my comments. The fact is that people engaged in any
endavor are, on average, mediocre. (As far as I'm concerned, the real
problem is not mediocrity, per se, but the level of incompetence at
which the present mediocrity presently rests. People following the
traditional career path now present in software simply do not have
enough time to get good enough to overcome this.)
Perhaps your objection is based on a misunderstanding of my point. So
let me clarify.
The point of my remarks was to highlight the dilemma facing language
designers: do you optimize your system for the wizards (thus requring
a greater level of competence to use the tool correctly), or do you
optimize for the mediocre (thus limiting what the wizards can do with
your tool)? Different languages have taken different positions.
Industrial software development is full of economic obstacles to doing
great things, or even hiring great people. It works in small groups,
but these success stories are never going to be the norm unless we are
able to change the way that people generally think about software
> My suggestion is that once BEA or IBM (websphere) acquires technology
> such as Ilog's JRules (you can buy me a beer for suggesting that :)
> and bundles it for < 400$ (or price for .Net CD's :) my view is that
> such end-user problems will disappear and the entire SI & custom
> app. market can and will cannibalize itself.
But decades of history are against you. How many of our programs have
ever disappeared? We repackage them, and hide them for someone else
to deal with, but the problems themselves are not gone. When has a
tool alone solved any problem in software development? Tools do no
good if they are not adopted, and now we're back to the problem of the
requirements for a successful tool in industry having much more to do
with factors that will ease adoption.
We've known about buffer overrun problems for over forty years, and we
have worms taking out large pieces of the Internet by exploiting such
ancient errors. This hasn't been a problem for Lispers. It isn't a
problem for Java programmers. But these environments still don't have
sufficiently widepsread adoption for buffer overruns not to be a
problem for the Internet.
The question is why. Enter the built-in resistance to new tools and
techniques that exists in the typical industrial software environment.
People making decisions about such "corporate standards" rarely know
much about the advantages of one language instead of another. They
look at market share, support options, and their own PRESENT
CAPABILITY (rather than POTENTIAL CAPABILITY) to tell the "mere
programmers" what tools they will use.
Most people don't buy one car over another because the car is better.
Most people buy the car because it has cupholders. Perhaps this is a
lesson that we would do well to consider in software. It's not enough
to solve the programmers' problems -- as far as IT directors are
typically concerned, any programming language will do that, and in
theory at least, they're right.
So do we find a way to build cupholders into our software development
tools? We've already done that, many times over, in programmable
programming environments. So why don't the cupholders result in
widespread adoption of the environments that have them?
If people chose cars the way that they chose software tools, there
would be minimal concern for matching basic needs. (Steering wheel:
check. Brakes: check. Accelerator: check. Now, on to the important
things: base price, fuel economy, and maintenance costs...) Looking
at things from that far away from the problem will never reveal the
importance of a cupholder.
What needs to change, if we're going to succeed in building software
that doesn't suck, is the way that many decisions about software
development tools are made. Curiously, in my experience, in the
environments where developers choose their own tools, the programmers
are unusually skillful, often doing more with less.
For most industrial software shops, that's a risky proposition. See
my previous message for the role of risk aversion in perpetuating this
Matt Curtin, CISSP, IAM, INTP. Keywords: Lisp, Unix, Internet, INFOSEC.
Founder, Interhack Corporation +1 614 545 HACK http://web.interhack.com/
Author of /Developing Trust: Online Privacy and Security/ (Apress, 2001)