Ask HN: How do you sell in a new programming language?
29 comments
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.
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.
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/
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.
Pro Tip - Just give them his link 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.
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.
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".
In the enterprise world this is done via user groups - 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".
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".
"Nobody every got fired for buying IBM"
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.
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.
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.
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.
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.
That works, only if that company want to hire the best, instead of cheap.
I have build a career of be the "contrarian" in tech (Use Fox instead of VB, use .NET instead of Java, use Delphi instead of C++, use python instead of PHP, etc), and despite the argument here, is harder to sell. And that include the fact that the managers I have meet truly imagine that I'm the "Best of the best of the best!"
And that mean, no business. ROI be dammed, cheap sell better
I have build a career of be the "contrarian" in tech (Use Fox instead of VB, use .NET instead of Java, use Delphi instead of C++, use python instead of PHP, etc), and despite the argument here, is harder to sell. And that include the fact that the managers I have meet truly imagine that I'm the "Best of the best of the best!"
And that mean, no business. ROI be dammed, cheap sell better
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.
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.
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.
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.
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!
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!
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.
- 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.
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!
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!
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.
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.
Are you respected? Because I’d say don’t even bother trying if they don’t respect you
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.
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.
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.
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.
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.
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.
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.
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.
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.
- 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.
- 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.
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.
So in essence, how it makes an average joe like me more productive/powerful.
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.
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.
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.
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.
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.
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).
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).
"In the JVM ecosystem, no one needs to know that the JAR actually contains Clojure code."
That's an important point. It's going to be a lot harder to convince your company to make changes that require major work on the operations side, since those kinds of changes need to cross more departmental or political boundaries. Moving from C# to Clojure would be much harder, since if your company has been using C# exclusively, it may not even have JVMs installed on any of its production servers.
That's an important point. It's going to be a lot harder to convince your company to make changes that require major work on the operations side, since those kinds of changes need to cross more departmental or political boundaries. Moving from C# to Clojure would be much harder, since if your company has been using C# exclusively, it may not even have JVMs installed on any of its production servers.
Managers only understand about resources: time, money and human.
And percentages.
And percentages.
Most managers think that 100 plus 10% minus 10% equals 100, so I'm not too sure about those percentages.
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
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
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.
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.
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.
Implement something useful. Be useful. Better to ask for forgiveness than ask for permission. Only way it works.
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.
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.
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.
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.
> Better to ask for forgiveness than ask for permission.
You can say that again; I forgot this rule, and it cost me quite a good job. It's hard for anyone to argue with a fait accompli.
You can say that again; I forgot this rule, and it cost me quite a good job. It's hard for anyone to argue with a fait accompli.
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.)
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!
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!
(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.
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.
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?
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?
What makes you sure that your implicit assumption 'new == better' is correct?
What kinds of arguments do you use? What kinds of arguments actually work?
What strategies for transitioning to the "new" have you proposed, and what has actually worked out in real life?