[erlang-questions] Trying to change things

[Bernard Duggan]

 Hi João,

On 4/07/2010 10:02 AM, João Henrique Freitas wrote:
> Hello,
>
> I am working on a place wich uses the CHILL language programming to
> develop a huge telecom system. We use others languages too like C and
> C++. But CHILL is the largest code base.
We were in almost exactly the same situation as you a couple of years
ago, minus the CHILL - we were just using C/C++.
> I staring to learning Erlang about six months ago and in the last
> three months I spent a lot of energies trying persuade developers to
> change from CHILL/C/C++ to Erlang.
We did that when we first discovered Erlang too - doing that without a
lot of stuff to back you up (see below) is almost certainly doomed to
failure.
> But is hard change things. Anybody have some experience with these situation?
Yes, indeed I do :)  I'm not going to proffer what I'm saying as general
advice, but it's what allowed us some progress in our particular
situation.  Here's what we did:

* Start, in your "spare time", to write something in Erlang that's going
to be useful but doesn't exist yet because "we'll get to it later,,,when
we have time" :)  (Make sure you treat this as a learning experience -
you /will/ look back at this code in a couple of years and marvel at how
terrible it is, I promise you :)).  In our case, one of the biggest
problems we had was that we had no good way to test how the system would
behave when we plugged 3000 phones into it, because we had neither 3000
phones nor the 3000 QA guys to run them :)  Erlang's concurrent nature
made it a perfect fit for this kind of role - acting exactly like a
whole pile of phones.  After a few months we suddenly had a tool that
both allowed us to do something really useful and showed off Erlang.

* Make sure everyone knows how awesome this is, and that they know that
it's awesome, at least partly, because it's in Erlang (and also,
naturally, because /you/ wrote it :)).

* Hopefully, people will start asking "why doesn't it do X?" (though
they'll rarely marvel at how something useful sprung up without them
having to do anything or even ask for it - it's all about what it
/doesn't/ do).  Once again, you can show how nice and easy Erlang is to
modify by adding X.  But make sure you /show/ them how easy it is to
add.  Maybe they might want to add the next feature themselves (because
you're really busy right now...)?  Hey look - you have another person
writing Erlang :)

* Make sure you read up on all the great stuff Erlang can give you -
especially the reliability and "safe crashing" aspects.  Telco people,
especially, /love/ reliability for obvious reasons.  We have a process
where one single bad pointer can take down 5000 phones for 20 seconds -
imagine how aweomse it sounds if a bug in your code will, in all but the
worst possible cases, take down only one or two!

* This step is where, I think, we got a bit lucky - we started actively
agitating to write new bits of the core code in Erlang.  Depeding on
your system, that's probably going to have a high startup cost in terms
of writing a layer to interact with the legacy code.  Somehow we
convinced them it was, in fact, the "way forward", but we didn't have
time to convert anything that we currently had (fair enough - it was all
"working" okay).  But then we got another lucky break when we were asked
to write a whole new module for the existing core system, and the job
was given to the two biggest Erlang users :)

* This time, we didn't try to sneak it "under the radar" - we said we
wanted to do it in Erlang, said there would be a certain cost to getting
the initial interface layer written, but also made it clear that we were
totally convinced it would pay off, even for this single module.  Based
in no small part on our earlier success with the testing system, we got
the go-ahead.

* The only other suggestion I can give is, if you get to that stage,
take as much time as you can to make sure you get the first serious bit
of Erlang stuff "right".  If you still have nay-sayers, they will be
looking for any little thing that goes wrong as a way of saying "see? 
Told you Erlang was rubbish - we should be sticking with good-ole
reliable C++".  Never mind that the C++ stuff crashed twice a day when
they first coded it :)

Like I said, that's just our story - it may or may not be any use to you.
> My boss question me about 'Who is using Erlang?' and I am trying to
> found some in my country (Brazil).
Can't help you with that one, sorry (not for Brazil, anyway).  What I
/would/ say is that it's entirely typical of "management" to take the
"well if it's so great, why isn't everyone else using it?" attitude. 
I'm sure it's self-evident to everyone on this list why that very
question itself is wrong, but it's the job of management not to screw
up.  If they have something that is seen to be working (for some
definition of "working"), the choice they see is between a "zero risk"
option of changing nothing or a risky option that some guy is telling
them will make things better.  It's always the easier choice to stick
with a known quantity.  I'm not meaning this as some kind of
"anti-management-they're-all-morons" rant - they have a different
perspective on things and I can totally understand their reluctance to
move away from a known quantity.
> Now I can't waiting more and start a internal project to interfacing
> with CHILL/C/C++ old base and Erlang.
Good luck!  Let us know how you get on.

B