
Ask HN: How do you sell in a new programming language? - simenfur
People who are passionate about programming often find themselves with a need to convince their organisation that it is time to try something new. Resistance against this kind of change is often entrenched, and a long struggle awaits.<p>What kinds of arguments do you use? What kinds of arguments actually work?<p>What strategies for transitioning to the &quot;new&quot; have you proposed, and what has actually worked out in real life?
======
patio11
The same way you sell a business anything else: it will raise our revenues
and/or decrease our costs.

Rather than saying "We should reimplement our core products in $FOO" you can
often achieve the result of using $FOO while hitting less resistance by
implementing one-off projects or support systems in $FOO instead.

e.g. I worked at a Japanese megacorp and, despite us being a Java shop, one of
the sales guys sold a customer on "We're certainly the right people to write
documentation for your Perl program." This contract only required a bunch of
HTML files as a deliverable, rather than getting a team of programmers to
speed on something which would be maintained for 30 years, so I successfully
convinced my boss that I'd jump on the Perl grenade if he let me use any means
necessary to create the HTMLed documentation. I ended up doing it in Ruby.
Then I had a "Hey boss remember that time I delivered a $X0,000 project in
1/4th the budget and made you look like an effing hero? I want to use that
tech again" case study.

Though for the amount of time I spent on evangelizing Ruby and modern
Javascript-heavy UIs at my previous company I could have launched my own.
Eventually I did. It turned out to be a much better use of my time.

~~~
mbesto
This. Node.js and Rails are sexy right? Show your boss how. Do a video screen
capture of the time savings you get. Also, execs like what we used to call
"The NASCAR Slide™" \- which is a presentation slide with all of the logos of
companies who use those technologies. The more Fortune 500 companies, "the
faster your NASCAR car goes".

Pro Tip - Just give them his link
[http://www.walmartlabs.com/](http://www.walmartlabs.com/)

Note - Be prepared to have the ugly discussion around support and ecosystem.
These are arguably the biggest cons to "newish" frameworks. The problem for
any technologically lagging organization is that they don't have the resource
(both human and capital) to support change.

~~~
simenfur
A screen capture sounds like a very good idea, as a nice way to visualize.
People tend to buy based on emotions, and then rationalize with logic. The
screen capture sounds like an appeal to emotions, while "the NASCAR slide"
would work as justification.

~~~
rmc
The "NASCAR slide" can also appeal to emotions, as a form of peer pressure.
"Oh I wanna be like the big guys, and the big guys use this, I should do what
they do".

~~~
mbesto
In the enterprise world this is done via user groups -
[http://www.sap.com/communities/user-
groups.html](http://www.sap.com/communities/user-groups.html)

You'd be surprised how often competitors (let's say BP and Shell for example)
make purchasing decision after discussions at user group events, simply "to
keep up with the Jones's".

~~~
rmc
"Nobody every got fired for buying IBM"

------
fecak
One 'argument' that people don't often think of is recruiting and hiring. I
recruit for many companies, and the level of applicants I receive for jobs in
the more emerging language communities is well above the applicants I usually
get for more traditional languages. My evidence is anecdotal, but when I
posted Clojure or Scala jobs (and recently Go) I received fewer applicants!
but almost all of them were highly qualified engineers with very impressive
track records. The applicants also come from all over, because of the novelty
of the jobs. Java jobs tend to get local candidates, but a Clojure job gets
applicants worldwide.

Most of this is with startups, but I've even seen serial startup engineers go
to work for large companies who use an emerging language.

Obviously this is a side effect that depends on the language chosen, and it
doesn't justify that the code or product will improve, but if you are making
the argument this could be a consideration.

Of course, the counter is that experienced talent in the emerging language may
be more scarce.

~~~
michaelochurch
_My evidence is anecdotal, but when I posted Clojure or Scala jobs (and
recently Go) I received fewer applicants! but almost all of them were highly
qualified engineers with very impressive track records. The applicants also
come from all over, because of the novelty of the jobs. Java jobs tend to get
local candidates, but a Clojure job gets applicants worldwide._

My observation (at a Baltimore company) was the exact same. When you post
Clojure job ads, your pool becomes national and get rock-solid people who'd be
top-2% in the Java pool. The difference is night and day.

The location is a disadvantage, except for local candidates. (There is a lot
of talent in Baltimore-- more than you'd think based on the city's
reputation-- but the set is small and quickly exhausted for a larger company.)
Great programmers who don't mind using Java or C++ have moved on to hedge
funds or upper management in the Valley by age 30. Convincing them to take a
risk on a geographic move won't happen. The Clojure pool is national-- there
are some really great people who will take that risk if you can promise them
full-time work in their preferred language. (Being able to make this promise
is rare.)

That said, as a sell to upper management, this argument tends to be
unsuccessful in my experience. It is 100% true. But the way it sounds is,
"People who like the same languages as I do are way better." You can probably
understand why managers are skeptical of that claim-- as true as it is.

What's happening in software is that, because 90% of the work in the industry
is mindless, ticket-munching bullshit (CommodityJavaDrone stuff) the top
programmers are all finding ways to distinguish themselves-- this is something
you have to start thinking about by 28, and you have to have a path by 32,
lest you be confused for a CommodityJavaDrone and be put on bullshit work (in
which case you'll be flushed out by 40)-- as "too good" for junior-level,
predigested grunt work. Some become "Data Scientists" or "Machine Learning
Engineers" or "Research Engineers". Some learn a lot of nontraditional
languages (Clojure, Haskell, Rust). The few who have the connections become
startup founders. Others get "special" engineer titles in big companies
(Principal Staff Architect XIV). You won't get anyone good (meaning top 5%)
over 30 unless you can establish that the job is "special"\-- that they won't
be lumped in with regular ol' engineering plebes who have minimal autonomy and
are basically there to do what they're told-- but managers see that price of
talent as a political risk they'd rather not take. It's hard to address these
sociological facts (as one of those "older" (30+) top engineers) without
coming across as an arrogant twat. The CommodityJavaDrone engineer mentality
is borne of a managerial misconception that those older, top engineers aren't
needed, that one can just hire college kids on the cheap and mash them
together as if they were all the same... but it's completely wrong. A tech
company rots if it can't get top talent.

~~~
simenfur
I like the honest career advice :) I agree that a tech company should get top
talent, but "older top engineers" are often very resistant to change. Say, as
JavaScript has gotten more and more important, it might be hard for those who
have built careers around specific languages to move on to something else. On
the other hand, younger talent are often more open to this kind of change.

------
dev99
I worked for a place that used a dying language. The argument I used was
simple: If you stick this technology, your employees will worry about their
careers and leave, AND you will find it harder and harder to recruit new
people who are interested in this language. Good developers will want to work
in exciting and living languages to further their careers and keep their
skills up to date. So the only developers you will find are the ones who will
"settle" if they can't find another job, or use it as a stepping stone until
they find a different job, or demand a high premium to do it.

There seemed to be some openness to studying the alternatives, but ultimately
it was hard to convince the powers that be that it was worth the effort to
adopt a new language/technology.

So I quit. The only regret I have now is I didn't do it sooner. I wasted a lot
of valuable time.

------
implicit
I convinced the company I work at to use Haskell for REST services.

The technical leadership team was already interested improving the reliability
and rigor of our web backend, but weren't thinking about exploring other
programming languages. (we primarily use PHP)

I knew Haskell would be hard to sell, but I also had concerns about it myself,
so I ran a live-fire test:

In my spare time, I wrote an interface-compatible Haskell implementation of a
particular service that drove a lot of load, but was noncritical. I load-
tested this service by flipping an nginx switch to divert traffic to the
Haskell implementation. Leadership was ok with this because we could just flip
the switch back if there were any issues: The risk of customer impact was
miniscule. After some initial tests, we left it to run for a few months
without manual intervention.

Over the course of this side-project, I got a few curious coworkers to learn
Haskell to help out.

When the right project came along, leadership still had concerns, but I had
lot of hard evidence to show that Haskell superbly fit our technical
requirements and that the nontechnical problems (like hiring and training)
were probably surmountable.

------
binarymax
A contractor and I successfully convinced our large enterprise that node.js
was the best choice for a new project and we were able to use it. I dont want
to make this a conversation about whether node is good or not, but it did hit
the sweet spot as our goal was basically a RESTful API as a facade to some
legacy tech, which is in my opinion where node shined - and this was back in
early 2011.

The convincing arguments are:

1) the technology fits the problem - I would not use C++ for a web api, and I
would not use node for a rendering engine.

2) the team is (mostly) ready to use it - a couple weeks to read a book and
make a prototype should be enough. There is no need for lengthy and expensive
training sessions or a gigantic shift in technical knowledge

3) if it doesnt work out, you can double back quickly and cheaply

4) the new technology won't cost an arm and a leg - no need to find budget for
expensive licensing for software/tooling

5) you are not proposing this alone - get backing from other senior level
programmers/architects.

If you can hit most of those, then you probably have a decent chance!

------
Pacabel
Build something useful with it, prior to getting widespread buy-in. Build this
thing more efficiently than you could have using the existing tools. Make sure
the end product is more efficient, reliable, and robust than an equivalent
built using the existing technologies. Make sure these differences are very,
very significant and obvious.

------
z3phyr
Timing for the argument is very crucial. Your arguments for adopting a new
language will only work when other employees and your BOSS see your solution
run, and that at the correct time, when most of the people are not satisfied
with the current solution. If you are successful in demonstrating the pros and
importantly cons and other people support your decision, then there is 1%
chance that your boss will try!

I don't remember what happened clearly but I am able to recount one instant..

My father is a pro C# guru. His organization was having hard time investing in
a proprietary library. High costs had him thinking. I suggested him to use a
python based open source library. He asked me to mind my own business and not
to meddle in his affairs. That night when I came to his room to good night, he
was sitting reading the python documentation!

------
stcredzero
Implement something useful. Be useful. Better to ask for forgiveness than ask
for permission. Only way it works.

~~~
eps
That's wishful thinking when it applies to the choice of programming language.

If you come to a C shop and implement something in VisualBasic, you will de
escorted right out. Do the same but with Java and you will be _flying_ out,
through a nearest window :)

So - hell, no - it's not how it works at all.

~~~
stcredzero
_If you come to a C shop and implement something in VisualBasic, you will de
escorted right out._

Well, no duh! But I have seen things in unusual languages in large companies
become useful then become indispensable. Actually, I worked for a company that
couldn't have made $130 million/year if this were not the case.

 _So - hell, no - it 's not how it works at all._

Classic example of someone on the internet mistakenly (and overconfidently)
generalizing from their limited experience.

------
petercooper
While Ruby was growing in popularity prior to Rails, it took Rails to really
convince a lot of developers (including me) to switch from existing solutions.
I think there's a lot to learn from how that happened. (See SciPy or IPython
and Python for smaller scale examples of this story.)

------
parley
It may sound ridiculously obvious, but I think it's often a matter of being
able to empathise with whoever you need to convince. Most organisations are in
it to make money, and different people are different pieces of the puzzle of
achieving that. If you can express the upside of the technology shift in terms
relevant to, say, business developers or managers, things get easier. Whether
you have closures or not doesn't matter, but time to market, time spent on bug
fix releases instead of feature releases, etc do. Also, it will probably serve
you best to thoroughly and honestly present both pros and cons. There's almost
always cons (training, toolchain or workflow changes, building competence,
talent availability, unclear longevity of technology being switched to) so if
you're not upfront with the cons, people will wonder what they are and not
knowing is scary, risking a higher susceptibility to scepticism. Also, if it's
possible to use the new tech for a small project and you can show the upside
with clear metrics, actions speak louder than words. My two cents.

~~~
simenfur
It may not always be so obvious, so I think this is good advice. It can be
hard to understand where everybody comes from, and expressing the upsides in
terms that others really understand can be even harder.

------
tobz
(We haven't actually switched yet, and there isn't significant progress on
doing so, but the attitude change was decent)

We use PHP for most of our web stack at work. This includes long-running
consumers that are part of our growing service-oriented architecture. PHP all
over. It's hard to say "no" when everyone is familiar with it.

We've dealt with pretty crappy performance, compared to other solutions, using
this setup. It puts a lot of backpressure on our publishers (we use RabbitMQ
as our messaging layer) and it causes queue build-up, which requires manual
intervention, etc etc.

I had mentioned how we should switch to a better language: didn't go that
well. We have a lot of code written already: nothing insurmountable to
rewrite, definitely <10k lines of good code, excluding boilerplate-y stuff.
It's nearly impossible to get people to drop other priorities to _try_
something new. It has to be a more sure shot.

One of our developers, though, wrote a test application in Java to show how
much faster we could be consuming and processing messages. He actually
replicated one of our simpler services, which isn't much more than turning the
messages into rows in a MySQL database. I believe the Java consumer had a ten-
fold performance increase over the PHP one.

So, now, we have a few internal working groups for various tracks of
improvement to our product, and one of those groups is exploring Java as a
possible language to switch to for this area of our infrastructure. We have
people dedicated to actually vetting it, not just talking about it at the bar
or something.

Long story short, and to echo everyone else: you can't just tell people
there's something better, you have to show them something better.

------
rjzzleep
arguing beforehand for the language itself never worked for me. for me it's
always been easier to get the other developers interested, and then deploy a
working project with it.

asking beforehand for me always led to a wide variety of different arguments
of why we can't use a different language. the most common two being the
following ones.

* we can't find new developers with that experience

* our developers don't know it

------
romanovcode
Depends on who you're selling to. Here are few categories out of top of my
head.

\- Make website very fancy with videos and do many useless benchmarks showing
that it's faster then everything, especially Nodejs

\- Create VM language and show that it's just as good as Java but with much
more syntactic sugar. Also note that C# runs only on Windows and yours run on
everything.

\- Do a static compiled-to-bytecode language that will be just as fast as C++.
This is very hard so you can forget about this.

\- Create another "language" that will compile to Javascript.

------
wallflower
Well, I personally know one high-level technical individual who almost got
fired for daring to use Spring in a heavy J2EE shop. He survived and Spring
makes the product so much better (for those who don't know - Spring is
basically what J2EE should have been - lightweight and high performance
framework)

You basically have to appeal to emotions (they won't understand the technical
argument or even care). But if it makes the product more stable, more easily
extensible/customizable - that could work.

Good luck!

------
mmphosis
Stop arguing. I'm a programmer, not a salesperson. $FOO (a new programming
language) needs to sell itself.

Cost. What is it going to cost?

Benefit. What are the benefits of using $FOO?

The answer is: it's going to bring in revenue.

$FOO needs to be adopted because it is popular, it is an industry and open
standard.

> Do we need to convert everything to $FOO?

The answer is: no.

> Do all of the programmers need to learn $FOO?

The answer is: everyone already knows how to programs in $FOO.

I'd be curious to know what the "entrenched" programming lanaguage is, and
what the "new programming language" is.

------
gyepi
A lot of this depends on the organization, its perceived needs and the
personalities involved. No doubt some of the answers you get here will be
helpful, but I would focus on the particulars. The first question is whether
the organization actually needs a new language or whether you just want to use
a new language.

Depending on the environment, the change will bring its own set of
difficulties and those will need to be addressed. Sometimes, it's a matter of
the people involved. For instance, you are the only one passionate about a new
language and others are not or is willing to learn and others are not, etc,
then you suddenly have a new problem that may not have existed before,
including having to support your colleagues through the transition.

As for arguments, etc, those should arise from your situation. If the current
system is not working, make that clear. You may have to repeat yourself to get
the point across. But do your homework first. Know what's broken and how your
suggestion will fix it. Know the advantages of the current system and the
distadvantages of the new one. "Trying something new" does not seem like a
good reason; surely there's a reason why you use language X?

------
parallelist
Are you respected? Because I’d say don’t even bother trying if they don’t
respect you

------
727374
Have a plan for how it will integrate with your existing ecosystem such as
tools, version control, continuous integration, data sources, etc if your org
requires these things. I once worked as a principal at a .NET shop and had a
smart engineer come to me wanting to use nodejs for part of a project and had
to gently turn him down. I love to see enthusiasm for using new tools and
personally like node/javascript, but his plan to use node didn't address
important process concerns like hooking into our existing deployment, CI, and
unit tests. Those concerns could have been addressed, but would have required
significantly more effort than the actual project itself. Every org is
different, but for us adding something without proper automation/tooling was a
sin.

------
joesmo
If this isn't obvious to your use case, there is no business reason for trying
a new programming language and you are doing the whole business a disservice.
I should never have to sell a new language or technology. If it's something
the business needs, the uses will be obvious.

~~~
simenfur
Thinking that something sells itself is an engineer's mistake. I'm an engineer
myself, and I have learned through experience that quality is not enough.
Selling is important.

~~~
joesmo
You're confusing selling with having a business use. There's a huge
difference. The OP doesn't have a business use, therefore no business (pun
intended) to sell anything.

------
fauigerzigerk
Honestly, I think you can rarely make a convincing case based on technical
merit or productivity promises alone. There are often good reasons to be
conservative about technology choices.

I would try it from a different angle. If the organization wants people who
are able to come up with fresh ideas, these will not be the same people who
are content with using only very mature technologies. If the organization
wants to cultivate an innovation mindset and be attractive for innovative
people there needs to be space for experimentation. Who knows what comes of
it.

Maybe that's the point where you get fired. If you were hired by an insurance
company to maintain their 2002 style J2EE monster that's what's going to
happen.

------
musesum
There once was a company called Digital Research (DRI). They had a successful
language called CBasic. A friend that worked there tried to convince them to
develop a compiler for another language called "C". They refused. He insisted.
The result: "they fired my ass!" Later, DRI wrote a C compiler. Was it too
late? Would they have been successful if they had written it sooner? Maybe.
But, then that would have been a different company. Perhaps, another way of
looking at it is that my friend was giving his company a job interview and, in
his case, they failed.

------
tremols
Does your new language improves productivity, maintainability, code
reusability, performance, etc?. Does it allow new crazy esoteric tricks with
one line of code?. Does it bring a paradigm shift?.

Otherwise if its a new syntax for the same old thing - specially regarding
imperative programming which to me already reached a dead end - it will be
hard to sell. If you're thinking of a market strategy then your language is
lacking enough innovative features that make it sell itself.

------
stephen_mcd
\- Make a list of successful companies using lang X. Bonus if competitors.
They're a success because of lang X.

\- Will using lang X over Y reduce total lines of code? That's less work, less
time, less money.

\- Are # jobs for lang X rising? Show some pretty graphs. We can't fall behind
the market.

All of this is bullshit to an engineer, but precisely how you need to sell it.

------
eklavya
Show that it decreases LOC while improving/maintaining readability with
performance at par with current ones OR great performance without too much
compromise on LOC count and readability.

So in essence, how it makes an average joe like me more productive/powerful.

------
ExpiredLink
What makes you sure that your implicit assumption 'new == better' is correct?

------
hluska
If I were in your shoes, I would spend some time trying to research why your
company is actually resistant to change.

Some managers are extremely resistant to change because they work in
organizations with extremely vertical power structures. Consequently, they
know that even if they think it is a good idea, they are going to have to sell
it to 15 different people and get each to sign off on it. In some
organizations (government is an excellent example), a manager would have to
write a report to get permission to write a report investigating a new
technology. In organizations like this, experienced people (aka - management)
generally have horror stories about the time they spent three years getting
permission to upgrade all the computers to Windows ME...

That brings up another reason that some organizations are resistant to change.
When the kinds of people who read Hacker News think of a new tool, they're
usually excited. People like us equate change with learning and improving.
Consequently, change is an adventure. Unfortunately, end users don't always
feel the same. For these types of users, "IT change" is synonymous with "pain
and torture". Consequently, getting permission to use a different tool is
usually only the first step. When you actually implement the project, you get
to deal with six weeks of whining, followed by another four weeks of training
extremely resistant people. And then, for the next several months, every
problem on earth is 'the new system's fault'...

And then, there are the sales people. Many managers have horror stories where
a sales person convinced them that this great new system would do A, B, C, D,
E, and F. Unfortunately, once the system is implemented, lo and behold, the
system barely does A and B. If you've ever been through a situation like this,
you'll be extraordinarily resistant to any new solution.

Once you know a little more about why your company is resistant to change,
you'll be in a better place to make a decision. Maybe you work for a giant,
monolithic entity that changes about as fast as granite erodes. In this case,
you might have to decide whether you feel comfortable in a company like that.
Or, maybe your direct manager got burned by a new tool and is forever
paranoid. In a situation like that, you'd be better off implementing a one-off
project with the new tool and proving that your solution actually works.

The general advice in situations like this is to show that a new tool will
have a positive return on investment. That advice isn't wrong, but
unfortunately, when people write about the ROI of a new tool, they usually
focus on developer hours saved. While that is a good metric, in most cases,
developer hours are just one component of a system's true cost. If you start
your analysis earlier, you'll have a better sense of all the other costs
involved and be able to speak to the real objections you will face.

------
br0ke
sell the result, not the medium. I've written code for fortune 100 companies
and gov't agencies in "crazy" languages like scheme and lisp... I didn't say
what technology I was going to use, I just told them what the result and cost
would be.

------
michaelochurch
So, to begin, this is really hard to do, and it can lead to the end of your
career at a place. Managers might think of you as That Guy, the one who is
always coming out with disruptive ideas. ("Disrupt" ain't a positive term,
here.) That Guy makes the manager's job harder because the manager wants a
unified front, not debate.

1\. It helps if the language interoperates well with the existing platform. If
you're at a Java shop, consider Scala and Clojure. Don't bother trying to sell
it on Haskell; that'll never happen. But, for Scala or Clojure, the top 25% of
Java developers are probably headed that way already.

2\. Don't ask permission of nontechnical management. (Grace Hopper: it is
better to ask for forgiveness than permission.) Just deliver something cool in
it that the rest of the organization can use. In the JVM ecosystem, no one
needs to know that the JAR actually contains Clojure code. Get enough momentum
behind the project that management actively wants you to demo it to the rest
of the company. Then mention the "secret weapon".

3\. After (2), get a job ad posted in the new language. The quality of
applicants will be a lot better. Post a Java job ad, and you'll get more
responses, but your phone-screen-to-hire rate will be about 2-5%. For a
Clojure job, it'll be closer to 30%-- and 60% of those who actually know
Clojure (those who don't will fail-fast on the phone screen). Not only can you
reduce time wasted with unqualified candidates, but you're more likely to get
a 10X hire. Now you can make the argument that it's worth hiring more people
in the newer, better language.

You're not going to turn a large Java shop into a Clojure company. It just
won't happen. But if you do the above and have a bit of luck, you might carve
out a CoE (Center of Excellence, also known as an "honor's college", which
tends to be an elite suborganization that has an R&D flavor) in the
organization that uses it.

That above only works if your company has generally good management. (They
don't need to be programming language specialists, but they need to be good at
their jobs.) If not, you're not going to get anywhere no matter what you do
and it's not your fault. Then, the best bet is to move on.

~~~
simenfur
I agree that it is hard to do. If it can't be done, though, only the death of
companies with old tech will make the world move on.

I think 3) is a good tip, and I have seen it work for some local companies who
moved to Scala (for parts of their code).

------
Eleutheria
Managers only understand about resources: time, money and human.

And percentages.

~~~
simenfur
Most managers think that 100 plus 10% minus 10% equals 100, so I'm not too
sure about those percentages.

