In this article, author Dianne Marsh lays out a business case for using new languages by comparing Java and Scala:

http://www.artima.com/scalazine/articles/a_business_case_for_new_languages.html

What do you think of the author's argument?

I've attempted this argument (or ones like it) with business staff before, with similar reasoning (though without car analogies :-).

I always get the response that this line of reasoning is more about why moving to a newer technology is not as bad as it sounds, not why it is actually a good choice.

Before we get to the bottom line reasoning that is really the only thing business-types seem to ever respond to, I think we need a stronger, positive case for why upgrading our technology stacks is appropriate, not just less bad than the worst case a non-technologist can dream up.

For example, there are some studies showing that programming in higher-level languages is more efficient. How about a comparison of how much more efficient, versus the time it takes to learn the language well enough to be proficient.

Measures of what types of people learn new languages fastest would also help, because new hires are more likely to need that language training. Information on when the transition of various systems to the new language needs to occur must be provided (granted that this is less of an issue with Java to Scala). Library support needs to be determined (again less of an issue with Scala). Etc etc.

I think this article is good at presenting necessary information to decision makers. I just think it's not a sufficient amount, and we should work to put together a more fully-developed case for upgrading.

Thanks for a thoughtful post!

One more thought.

Licensing issues aside, the technology team rarely asks permission of the business team to bring in new libraries or frameworks (unless their use results in a large scale rewrite).

Yet we agree that a case must be made in order to upgrade to a new language.

If we focus on the differences between bringing in a new library and upgrading an entire technology base, that might give us a boundary on the areas we need to cover when making our upgrade case.

I think part of the problem is that these kinds of arguments boil down to "newer is better" which is really not a rational argument at all. Sometimes newer is actually worse. If we think back to why Java was able to gain traction, I think might help to explain the kind of reasons a person with business training needs to justify this kind of switch:

* Java promised (and largely delivered) portability across operation systems. This gives a strategic advantage. Anyone who knows basic game theory understands this. This was the strongest business argument for Java.

* Java promised robustness. You can argue about how much it delivered on this but things like garbage collection and array bounds checking play to minimizing uncompensated risks.

* Java promised simplicity. Again, arguable but the pitch here is that finding qualified people would be easier and therefore less costly.

If you want to sell a new language like Scala, you need to make these kinds of arguments. One of the big problems that you have is that if a business chooses a language that is not widely adopted, its generally very disadvantageous. New languages are not not widely used which limits their adoption. A bit of a Catch-22, I would say. If you can show that companies are adopting it or that developers can either be found or easily trained, this might help. As far as Scala goes, there's a general impression that its hard to learn which is likely (assuming that doesn't change) to prevent wide adoption.

Lastly, the smaller your organization, the easier its generally going to be to adopt a new language. At larger organizations, the people choosing languages and tools tend to not be the people who use them or have the skills to understand the merits of one over the other.

I don't think this is sufficient argumentation for why an org should embrace Scala. Businesses wants established standards over the latest flavor, and Scala is still quite a unique flavor that divides more than it unites. That's just a fact when you look around! Scala is like salt liquorice. We need something more like chocolate or fruit gum.

First, I thought the automotive analogy was a bit confusing. Since Java and Scala run on the JVM, there isn't anything you can do in Scala you can't do in Java, so cigarette lighters, poor fuel efficiency, etc. don't really seem valid. That's just bad, outdated coding.

I do believe there is a business case to be made for Scala, but don't think this article makes it. First, there are no numbers! That's essential for a business case. The author made some comments that could lead to a business case, but I believe more on the amount of code reduction along decrease in testing and bugs because of less and more expressive code with numbers to back up the argument would be helpful. For me personally, I find that using Scala reduces my code base by about 50% (very rough estimate). That's less code I have to write, test, and debug.

However, as someone who knows C, C++, Java, Groovy, Ruby, and several other languages, I find Scala to have a pretty serious learning curve and the tools are still a bit less supportive than those for Java (although getting better). Switching to Scala requires getting the programmers to not only learn a new syntax, but also new ways of coding (functional, for instance)

I believe that over time Scala, or something like it, will replace Java simply because it does let those who take the time to learn it writer better code with a lot less work, but it's going to be a tough sell that probably needs to start at the bottom and work up.

One last thought. The addition of actors and functional programming's ability to scale should be a major part of the business case. These are much more difficult in Java, but are becoming major requirements for software.

- name all the companies that use scala. best is to name those which products your management uses - twitter, linkedin, maybe foursquare? :)
- recreate existing module in scala during your work time and claim it, so management can see and compare how much time you spent on module development in java comparing to scala. show them the cashflow! :)

in general, business people want to see at least a prototype. they need to see a result before they put a single thought to something new. sad? but true.

A new language has a chance in a business environment if it can either cut the costs or increase the profits or both in a substantial degree. In other words, the benefit should be big enough to justify the change.

I don't think Scala offers something significantly better than Java for most business cases. Especially for smaller shops, anything else than Java seems to be an overkill.

This article is a great example of how many developers don't understand the business world.

A business case is an ROI.

Where's the ROI for Scala versus Java in that article? ROI analysis (or similar tool) would quantify things like efficiency gains, reduced expenses, risks mitigated, etc.

What was the business case for java? It made it easier for the Fortune X00 to build nicely interactive web sites with applets.

Oh, you don't remember the last time you coded or visited an applet page? Unless you're on a X00 intranet, not likely.

Prior to java, the Fortune X00 coded mostly in COBOL and C. Some (many?) tried to repurpose COBOL coders to java; I watched and chuckled. COBOL and C persist, now with java the default web environment, although that sort of java tends to be structured just like COBOL but without the SCREAMING CAPITALS. One might conclude that COBOL won.

With java webservers and servlets, java was saved from an early death. Applets won't be missed.

The unholy trinity will go on for quite a long time until there is a new platform that none works very well with.

the web was still young, that's why java caught up ;) now, everything seems settled as you described.

> This article is a great example of how many developers
> don't understand the business world.
>
> A business case is an ROI.
>
> Where's the ROI for Scala versus Java in that article? ROI
> analysis (or similar tool) would quantify things
> like efficiency gains, reduced expenses, risks mitigated,
> etc.

ROI is just one way of judging the financial value of a project and really not a very good one. The financial value of a project is important but it is not the only thing that should be considered in a business decision. Its useful to attempt to quantify everything about a decision but the point is to help provide insights; not to dictate a choice.

If the classic ROI analysis is "not very good", what is a distinctly different and better way to quantify the business value of a change of technology to users?

I'll add that it's different strokes for different folks, but for anyone to push a change in a business based solely on intangibles should realize that the dot-com 90s have come and gone. There's got to be at least some hard returns.

This is an issue I'm dealing with right now. I personally like a Scala a lot, and have been writing all of my new (server-side) code in Scala for the past 1.5 years. I can personally see big efficiency gains, better code quality, better design, possibly more scalability, more agility of the codebase - I can see all that using Scala.

That said, I suppose the discussion about Scala as a business keys should be qualified as using Scala to write new code - old code, by definition is already written - or even in a new project.

If we restrict the discussion to new code or a new project, then I think almost any business today has to consider time to market as a key criterion for architectural, including language, decisions.

With that narrower context, the question then is, To what extent does Scala help you deliver a project / product to market quicker than technology / language X?

That more defined question then brings into play some of the considerations a business manager would have to weigh, such as: How easy is it to staff the project (given a finite budget)? How do the language and tools support reliable delivery in the face of a changing specifications and requirements, which are common in new projects? How easy is it to leverage existing infrastructure from the language (as compared to language / framework X)? And what kind of developers would Scala attract compared with, say, language X, and are those the kind of developers the project really needs? Etc.

Answers to some of these are more obvious than to others. Clearly, good luck trying to find experienced Scala developers (at an affordable rate, compared to, say, Java developers). Scala IDEs truly lack behind mature Java IDEs (even with the recently released excellent Eclipse Scala IDE and IntelliJ) -- expect those tools to get in the way quite a bit still, which will waste time. But Scala may attract some of the top developers to a project, so that's a huge plus, provided that your project needs top-notch developers (every project needs them, of course, but few can afford them!).

Introducing anything new, of course, causes a temporary dip in productivity. The question is, can you make that up as you gain more experience, given that your competitors may be working on similar solutions using some other technology which they may be experts in already? My experience is definitely "yes" -- however, it would be a mistake to underestimate the Scala learning curve, which may be bigger than the Java learning curve was for C++ or COBOL programmers.

You *will* traverse down blind alleys in design and implementation, and will end up throwing away code and redoing work, as Scala dictates fundamental design choices that only become apparent with experience. That's great for learning, of course, but there's a time factor involved. (Even after 1.5 years of writing mostly Scala code, I would not consider myself an expert. That was definitely not my experience moving to Java - first learning Java in 1995, by 1997 I certainly felt mastery of all the Java language and design constructs.) You definitely have to consider available training as a business requirement.

My experience is that Scala is still 1-2 years away from the tipping point where using it in general would make a compelling business case. The inflection point maybe a truly great IDE, some API or framework, I'm not sure. Once that point is reached, though, lots of business managers will be ready to embrace Scala, because the benefits will be obvious to them.