[erlang-questions] OT: Programming Language Selection as a Business Strategy

[Ulf Wiger]

2007/4/14, jm <jeffm@REDACTED>:
>
> There are quite a few pages and blog entries around by people advocating
> one language or another for various reasons. What I'm wondering is: Are
> there any academic articles evaluating the selection of a programming
> language as part of business strategy? I've managed to find a few papers
> about Information Systems, etc and business strategy including one
> journal almost devoted entirely to the subject, but am unable to find
> anything specific to language selection. This seems strange as the US
> DoD developed Ada and Ericsson developed Erlang in response in part to
> business needs. If anyone knows of any good references please send them
> my way.
>

It's probably more accurate to say that Erlang was developed in an Ericsson
laboratory in response to a perceived technology need. Bjarne Däcker's
thesis gives some good background on this:

http://www.erlang.se/publications/bjarnelic.pdf


It also mentions that Erlang was banned in 1998, due to perceived business
needs.
(For the newcomers, this ban preceded, and in part justified, the launch of
Open Source Erlang.)

I agree with Thomas that essays like "beating the averages" give an
interesting
angle on this question. Large companies will also worry about the cost of
diversity and lock-in effects. This is most likely much less of a problem in

small companies.

For large companies, aspects that will have measurable consequences include:

- Cost of training support staff in several different technologies, since
different
  products are developed differently
- Difficulty in aligning user interfaces and documentation, since products
do
  not share a common implementation base.
- Re-training costs when moving developers from one project to another
- Difficulty in moving product development responsibility from one design
  center to another.
- Difficulty in finding third-party suppliers and consultants for obscure
  technologies.
- Risk that a niche technology folds during the life of the product, forcing
  an expensive redesign.

Some would also want to include the need to use mainstream languages
since this is what job applicants are looking for, but I think this is
largely
a phallacy, even though in a narrow perspective, the argument does seem
to hold some merit.

Now for the problem: If you're looking to invest, say, $100 million in a
product development project, wouldn't you want to try to eliminate the
above challenges, if possible? And knowing how many other factors
influence the success of a large development project (large = more than
100 people involved), it is difficult to convince investors that betting on
some obscure technology (be it a programming language, an ASIC,
cabling, or what have you) is actually going to give measurable benefit
in terms of faster time to market, lower cost, higher quality.

After all, the name of the game for large companies is _not_
programming brilliance, but being predictable and responsive in
the eyes of large customers, and being able to deliver and support
product over many years all over the world.

Again, many of these problems are specific to large companies, and
Graham's "Beating the averages" holds that small companies cannot
afford average performance, and thus have to be better and smarter
than the big companies. By avoiding many of the pitfalls of choosing
niche technologies, they may "safely" choose them and benefit from
the higher productivity of using sharper tools.

I saw a video of Steve Ballmer talking to people at (I think) Harvard.
He was talking about the four phases of a company:
1) You have an idea, and try to bring it to market
2) You manage to get foothold, and milk it for all it's worth
3) You try to establish a culture for coming up with a new (1)
4) You recurse.

He said most companies never get past (1), while large companies
are typically doing (1)-(4) simultaneously.

We often talk about programming language selection as if it were
all about (1), but if one could do a real life-cycle analysis, it might
even impress someone.

BR,
Ulf W
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20070414/dfd64cf4/attachment.htm>