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?
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.
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.
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".
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 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 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
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.
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 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!
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!
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.
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.
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.
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.
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
- 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.
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!
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.
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?
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.
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.
- 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.
So in essence, how it makes an average joe like me more productive/powerful.
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.
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 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).
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.
And percentages.