[erlang-questions] Ways to get started

[Avinash Dhumane]

How would a Sales person get himself started? No, I am not a
programmer. But, I am tasked to sell an abstract form that embodies Erlang/OTP
as its DNA. And, my prospects are the CXOs in the enterprise application
software space. Please bear with me a little bit so that I can articulate my
difficulties.

 

I left IONA Technologies in 2002 (I was a programmer at IONA,
and worked on point/patch releases of Orbix). It seems CXOs at IONA did not
"listen" to Steve's appeal "to use Erlang". So, I take a
hint from him that CXOs do not like a proposal or invitation "to use"
yet another “name” of technology even though it can provide them better trade-offs
than what they have chosen for now and which are burning their pockets badly.
And, I have testified this at sufficient number of places in the field. So, I
am starting with this one-liner pitch sans the word “Erlang” to draw the
attention of prospects: "Fulfil SLAs economically in the presence of
faults and extreme load." (Yes, I picked up this from Joe’s thesis, and
twisted it for my sales purpose)

 

Obviously, I need to refine this one-liner further as I go
down the hierarchy of “Buy” decision makers in my sales drill at the prospect's
shop. I need to show them how their (business) application architectures have
developed the *resistance* property that simply resists reliability,
scalability and extensibility, which in turn costs them money. And, by
architecture, I mean the things mentioned here: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.
 The abstract form that I propose to sell,
then, begins to take concrete form in the context of the (business) function –
form follows function – which the prospect sees as bottleneck or money-leaking
hole. I seize it as an opportunity to insert my form (made of Erlang as one of the
central architectural elements) as a gold-link in the midst of several weak-links
that the prospect has. The goal really is to achieve 20::80 (effort::mileage)
ratio for the prospect and a “beach head” for me (for subsequent invasion in
the customer shop). 

 

I end up presenting my abstract form sometimes as an application
container, sometimes as ESB, sometimes as DBMS, sometimes as TPM (the
programmers in my lab implement Paxos protocols), sometimes as XTP; I basically
measure the water-depth of the prospect and his drifts and the technology buzzwords
he subscribes to and try to take an “interesting” standpoint for him so that I
can resonate with him and get him to speak about his pain points! I have
deliberately kept my form as abstract as possible, because Erlang lets me
concretize it rapidly with its economy of expression for a specific need of the
prospect to overcome the resistance he faces in the application architectures
he has put together, often, forcibly!

 

Well, my difficulty is that I was an average programmer in
imperative programming language a decade ago and since then had not been up to
speed with the “thoughts” (as oppose to “details”) behind mainstream
technologies out there in the field bleeding the enterprises. This might be a
blessing in disguise since I do not have to unlearn too many things for I haven’t
gone down the many roads that lead to failures, but I still need to be equipped
with the architectural elements that build the rustiness (resistance) in the
systems and be able to convey those to the potential buyers to help them
understand why they are bleeding and what I have got to offer them. However, I am not able to pick up the branches of
evolution of the technologies, along with their characteristics, that have made
it to the field and unfortunately commanding the sizeable market share. The
data that I have to scan is way too voluminous, and I don’t know where to get
started and proceed thereafter. 

 

Any insights or directions?

 

Many thanks!

 
--- On Tue, 12/7/11, Joe Armstrong <erlang@REDACTED> wrote:

From: Joe Armstrong <erlang@REDACTED>
Subject: Re: [erlang-questions] Ways to get started
To: "Mihai Balea" <mihai@REDACTED>
Cc: erlang-questions@REDACTED
Date: Tuesday, 12 July, 2011, 2:19 AM

After 30 years you will get the hang of this and be a good programmer.

Tools are no substitute for typing in small programs and
understanding exactly how they work. This is true for all programming
language. Programming is an art form, there is no easy way.
Like playing the violin - is there an easy way of playing the violin other
than by practising for thousands of hours? I think not.

/Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110712/ec0ed8f1/attachment.htm>