As a consultancy, we’re always on watch to see what might be the next step forward in the field of software development. I usually find that paying attention to what our developers are playing with provides a good clue.
These days, many of them are toying with Scala, and they are eager to try it out on a project. I have challenged them to come up with compelling business reasons to use Scala on a project, but they have come up short.
I figured I would help them find a good business case for Scala.
For software companies in a tight employment market like the one in Norway, most technical advantages are dwarfed by one concern: Access to good developers. It clearly doesn’t matter what kinds of technical advantages a new language can bring if you can’t hire any developers to work with it. On the flip side, if you can bring great developers to your project, you’re probably in good shape no matter what language you have chosen.
The question, then, is what language should you choose to maximize your access to good programmers?
To answer this, I started to investigate the job market in Norway to see how many jobs that were listed for developers, and what languages they required skills in.
Next, I fielded a survey that asked developers to say what languages they knew, what languages they use on a daily basis, and what language they would prefer for their next project if they could choose freely. In the survey they could choose between 23 languages based on a Programming Language Ranking from Redmonk, published in January 2013. 117 developers answered it. There is some selection bias because of the way the survey was spread, but even so it should be somewhat representative for developers in Norway.
With 88% of respondents knowing it and 44% using it on a daily basis, Java is clearly the biggest language in the survey. From these numbers, it seems obvious that Java would be the language to use to have access to the most developers.
Now, from my experience, developers often choose jobs based on what language they get to work in. Some would like to stay with a programming language they know well, and others would like to keep up with technology and work with something new. That’s why I asked what the respondents would prefer to work with next. In these numbers, a different picture is drawn. Having removed the languages used by less than 5 respondents of the survey to eliminate some randomness, Groovy seems to have the most loyal developers with 83% choosing to stick with it for their next project. On the other end of the scale, only 24% would stay with Java if given the option to choose freely.
Where would all those restless developers like to go next? It turns out that 41% of those who wanted something new would like to try Scala next. That’s way ahead of Clojure and Python on number 2 and 3, with 16% and 11%. Only 5% finds Java that attractive when they don’t already work on it.
Now we need the other side of the equation. What is the competition for developers like? What language skills are employers looking for? The number of listings requiring programming language skills, found by searching at Finn.no, the largest online employment website in Norway, shows that Java comes out ahead, with 224 jobs listed. Towards the other end we find Scala, with a meagre 8 listings and Clojure with 1.
Employers want developers with Java skills, developers want employers who give them Scala projects. There seems to be a mismatch.
To make it visual, let’s create a small experiment with the data I have collected. For the sake of the exercise, say that the 61 respondents that wanted a new language next are all the actively looking applicants, and that the job numbers from Finn.no represent all the jobs they can apply for. Now, you want to recruit a new 5 person team.
By choosing Java in this experiment, for each of the 5 positions you would compete with 100 other companies. On the other hand, with Scala (or Clojure), you would get to choose between 2 candidates for each position.
What would be your choice? You can have a look at the data yourself at GitHub.
There it is, my business case for Scala, all technological arguments aside.
Would you like to participate in a similar programming language survey that goes beyond the borders of Norway? Here’ the survey.
The Iterate Blog 
Its not easy to build programming proficiency as oppose to language proficiency. A good Java developer can easily pick Scala.
This is a fascinating idea.
The tendency of some businesses to hire candidates based on what acronyms they “know” seems like an all too common tactic these days, and it reveals a very shallow understanding of programming on the part of those businesses. As the satirical piece “What if Cars Were Rented Like We Hire Programmers?” puts it:
“Agency: What car do you drive today?
Applicant : I drive a 2008 Subaru.
Agency : That’s a shame. We don’t have a Subaru to rent you.”
Any programmer with a bit of experience and access to Google can of course pick up anything from ActionScript to VBScript, and realizing that will already broaden one’s access to candidates and put one ahead of the competition. But actively using a language as a means of attracting candidates takes it a step further.
Is it really true that developers choose jobs based on what languages they get to work, with, though? I often find that that’s about the only information companies share about themselves:
“* Must know JAXB, JQuery, Spring, Hibernate, Struts, etc.
* Must be extroverted and like skiing trips to Hemsedal
* You like a hectic work environment, irregular hours and late-night phone calls”
The first thing I think when I see something like that is “…But what is it actually like to work there?”
Access to good developers is easy once companies view them as enablers instead of cost-producers. Pay good developers top salaries (like the ones paid for managers you no longer need), introduce open-allocation and you will find that suddenly there is no more access problem. This is called the market economy and, believe it or not, it works!!
Scala is the best language ever. Java is a dinosaur of the last millenium. Today’s projects need to be coded in the new millenium’s language, and no doubt it is Scala.
Halleluja!
Scala FTW!
Relying on trend in business is risky. Scala is the new Jesus, everybody’s talking about but noboby met. Scala has a very steep learning curve that I doubt it will result in a mass adoption regardless the publicity and the resources Typesafe is spreading. Java 8 is coming soon with a tremendous lift that will shy away people from the Scala trend.
Alternatively, Groovy, easiy to learn, is discreetly attracting Java programmers who want to discover new paradigms they don’t find in Java without sacrifying Java, like conciseness, functional programming, parallelism, dynamic features, and also because Groovy has a rich ecosystem like Grails, GPars, Gradle, Griffon, and soon native language in Spring release 4.
If the choice of a the language is about increasing productivity, there are serious alternatives to Scala.
“Though my tip though for the long term replacement of javac is Scala. I’m very impressed with it! I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I’d probably have never created Groovy.”
Source: http://macstrac.blogspot.de/2009/04/scala-as-long-term-replacement-for.html
How can you compare things with benchmarking results from back 2009? Hey, 2013’s Groovy version 2.X compiler groovyc is as fast as the fastest JVM compiler which is, not scalac, but javac. If you feel secure with static, even though Groovy is a dynamic language you just tell Groovy 2 to compile static.
I think we all should try out things before we come to hasty conclusions.
You’ve clearly never used Scala. For a Java developer it has an incredibly flat learning curve. You just keep coding like you’ve always done, except using the slightly different Scala syntax. And then you start slowly absorbing the Scala concepts and idioms, and over time you get gradually better at the powerful Scala features. The exact opposite of steep.
The bonus when choosing Groovy, though, is you can hire any Java developer and he will (speaking from experience) be able to maintain a Groovy codebase from day one 🙂
That’s only if you want to hire “any” Java developer.
The first risk of course is that if you choose languages based on trendiness, you may be choosing developers who’re more interested in trendiness than in delivering value to their users.
The second specific risk with Scala in my experience is that even if the language is feature rich, the compiler is too slow to have a good feedback loop. I’m suspicious of developers who work with a slow feedback cycle.
Agreed completely! Scala is such an awesome language. But the compiler is too damn slow to developing something like a web app. I’ve switced to Clojure since 6 months, and although the REPL (or Ritz) takes some time to boot up, it’s all streamlined from there. I can change code and it gets reflected on the web page immediately. Same thing with Scala, except for the immediately part.
I don’t know Scala, but how ofted do you need to compile project while working on a website? In C# world, we usually write code and run tests in the background, and compile usually after finishing a story (depends on a size: from once every 30min to once a day)
A slow feedback cycle is actually good!
People tend to think more about the code they write if feedback is slow. There’s too many developers relying on their IDE to tell them what functions to call on what objects, letting the IDE figure out how to resolve their syntax errors automagically, etc. While all this is great to start (and needs fast feedback from the compiler), it leads to less thinking about what you want to do before doing it. Same for tests, if all tests are checked continuously in the background tendency is to fix the code for passing the test, instead of fixing the underlying bug. But clearly, your experience might be completely different.
Are you not using SBT (or Eclipse which uses SBT)? I have no problem, on a reasonable CPU, with incremental compilation feedback. It’s almost instantaneous. And apparently 2.11 is expected to have some speedups in the compiler also.
Meaning for a business it makes sense to look for scala developers which they have to pay less (because there’s competition for the one job). Developers on the other hand should look for Java jobs and ignore scala, clojure etc [not sure odersky and Hickey will like this ;-)] because businesses compete for the java-developers, so will pay better (according to economics 101) … although no-one really wants to code in java (once they have been to scala, clojure, …).
But what happens when closure goes out if fashion and you have a codebase to maintain? It seems to me that when those developers are done trying Scala they will leave you for the next big thing and you will be stuck on a platform with very few developers to support it.
@joshuathegravatar the point is to use a new language when it fits a valid case for a customer as a consultant. Not just because it is a fad at the moment. Would you consider Perl and ASP fads that you have a hard time supporting now?
I like perl, but I consider it a write-only language.
What happens when COBOL goes out if fashion and you have a codebase to maintain? It seems to me that when those developers are done trying PASCAL they will leave you for the next big thing and you will be stuck on a platform with very few developers to support it.
I think really having good developers regardless of the technology stack is essential regardless of the market you are in. To go with that argument I think that good developers should be able to work in almost any of the major languages. If they specialize in one but a projects requirements require another language then the developer should be able to shift for that case.