> 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.

I don't disagree per se but often the values put on things are somewhat arbitrary. You can't make too much of them. Generally, people will fudge the numbers to make their preferred choice look better.

For example, something like "this project will make us 20% less likely to suffer a security breach in the next year which would on average cost us $10,000,000" might be reasonable but are by no means 'hard' numbers. The numbers are simply guesses. Educated guesses at best. Sometimes trying to boil down things to numbers can hide really important information. It might be that a security breach could destroy a company. Does it help to explain the value of continuing to exist vs. not existing as a company? I'd say not, in most cases.

> 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?

Net present value (NPV) is the preferred method. ROI ignores the time value of money and has other technical issues such as you can have a ROI of a one year but then lose money for 10 years following that.

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.