I think one of the biggest learning hurdles when coming from Java is getting used to using the functional collection types. I remember when C# first introduced linq-to-objects my reactions went from disgust, to fear, to total and utter acceptance and "how did I get anything done without this!"
There wasn't really a vote, but we did have a group forum where objections could be raised. People who weren't onboard with Scala were in the minority and most of the arguments raised didn't hold much water.
We had two teams in separate physical locations. We worked together occasionally, but most of the time projects were fully staffed at one location or the other. The Scala change was fully supported at one of the office and not the other.
It wasn't too difficult to convince the CTO that Scala was the right choice. He's a big OSS advocate. From a technological perspective we were trusted to make the right decision.
I think what really sold the the rest of the management team was how much money we could save in licensing fees.
The process change was top down, yes, I think that's the only way it could have succeeded IMO. However, the Scala change was bottom up and by developers.
The Mindshare acquisition is a recent event that postdates our technology change (Sept 19).
That's incorrect. The technology change was bottom-up, by developers. Simon didn't intervene with his technical direction until we already had a couple of Scala projects under our belts.
I'm sorry you interpreted it that way. It wasn't a disaster and internally the general consensus was that it was a great success. I've made some amendments to my post to provide some more context to our initial process change.
I'm sorry this is how the article came across to you. Given similar sentiments from others on this thread I'll see if I can amend it to make it more clear.
When our CTO came onboard I meant to say that he gave a hard look at our development process, not so much the technology stack itself. I agree it's confusing since the post is about Technology Change and I'm probably confusing the point further by mentioning both the earlier process transition when our CTO came onboard and then the later Scala technology change.
Thanks for your feedback.
EDIT: I've updated my post to elaborate on why a new CTO was brought into the organization.
In the beginning there wasn't an initiative to migrate away from .NET. Management encouraged us to try new technologies all time and the BeetleJuice spike seemed to me like a good opportunity to try something new given its simplistic requirements.
From an organizational perspective, there was some discord about how expensive our Microsoft infrastructure was and how poorly it scaled. I won't blame Microsoft for all our scaling problems, as a lot of it had to do with our legacy architecture, but licensing fees were a legitimate concern. Management didn't have any clearly defined goals to move away from Microsoft, but when we started using Scala, Mongo, and other open source projects they took the opportunity to make the case for more migration of our infrastructure. This new direction was officially announced as part of our CTO's Technical Strategy message to the dev department (included in my post).
I've often said the same thing to .NET advocates at Empathica. In terms of language constructs, C# is closer to Scala than Java is to Scala. However, IMHO Scala still offers more than both combined. :)
Scala can work great in a large development team. Your sentiments about poor readability and maintenance have little to do with the technology itself; you could say this about any programming language.
People new to a technology have a tendency to flounder around a bit in the beginning because they're naive to common coding standards and principles. After those are found or established then Scala codebases are just as easy to collaborate with on than any other.
LINQ is a fantastic DSL akin to Scala's collection types. Odersky gives C# the nod as one of the few other traditionally imperative languages to have such a rich way of transforming data in his Functional Programming with Scala coursera course.
I do prefer Scala's collection types and for comprehensions over LINQ though. I find them much easier to read and more powerful.
The Technical Strategy email was sent out about midway through our adoption of Scala. I didn't explain the dynamics of our larger development department much in my post, but at that time we were essentially two teams in two different physical locations. The location I was at had already seen success with a few projects in Scala (BeetleJuice and the beginning of our API). Our CTO thought it was time to set a clear direction for the future of development department after an analysis of our current situation and discussion with members of the wider team.
Nobody was shown with the door. I'll admit there was some resentment, but nothing a well adjusted developer couldn't get over.
As I mentioned at the end of the post, one thing I would do differently in the future is make a stronger effort around consensus building about the decision. However, the Scala change started off as something small and organically grew into a legitimate alternative to the Microsoft stack. Going into our first project (BeetleJuice) we didn't anticipate the impact it would ultimately have on the organization.