Ross McDonald - Thatcham

I thought that people considering a move to Scala may be interested to hear how this transition went for us at Thatcham.

Thatcham Motor Insurance Repair Research Centre provides data to vehicle manufacturers with the aim of containing or reducing the cost of motor insurance claims, whilst maintaining safety and quality standards. We research efficient, safe, cost effective repair of vehicles and work with manufacturers to influence the design of new vehicles.

You can learn more by visiting the Thatcham site, a site you should know is under redesign and will shortly be available on a new Scala powered platform.

Of course our views are subjective, we have a particular context at our company. In particular, we are lucky to have a very open minded and supportive management team who respected the technical team's expertise regarding technology stack options.

Our team is small, but over the last year we have been tasked to rewrite the entire suite of research software within the company, and to create a new publishing platform to disseminate the data gathered by the research software. These two parallel projects are long running, comprising many, mostly web services based, modules. The need to rewrite our software stems from a transition to a more web services oriented technical world, and a desire to architect a more coherent extensible platform. We felt a small team needs to avoid firefighting, and must think things through clearly in order to not just survive, but evolve.

Why Scala? With Java, our primary concern was the sheer bloat involved in creating such a large architecture. We initially had a split down the middle of the team between JVM land and .NET land. It is noticeable these days just how far plain old Java is lagging behind. Finally we decided to use something better than both, use Scala with all the choice and power of the venerable Java ecosystem still on tap.

We use Scala exclusively across the server side and that's where the majority of the action is these days. We have traditional ORM oriented modules, distributed modules, publishing modules and traditional webapp modules. The challenge now is to find what we can't do with Scala!

Perhaps the most crucial of our modules or layers, are the distributed modules, here we make use of Scala's excellent concurrency ready concepts, and in particular actors / message passing. Our chosen implementation of actors is 'Akka', mainly for the very capable integration capabilities it offers. Effectively Scala and in particular Akka have made us cloud ready, scalable and confident that we are flexible.

How do you get started with Scala, and more importantly bring it in to the enterprise ? We found you start slowly. This allows Java and C# devs get fairly proficient in Scala quickly. Communicate a lot. Ensure the management understands the different ways Scala can be used. Let the devs know it's OK to write Scala in a Java style, then they will steadily harness it's power to a greater level over time. Don't be afraid to ask your questions on the mail lists, both the Scala and Akka list members are very helpful.

How has using Scala benefited Thatcham ?

• the power of functional programming, more choice than just OOP
• collapsing the inheritance hierarchy, alternatives to inheritance, reducing coupling
• expressive syntax, express your intention, solve problems cleanly
• everything is a library, make the language do what you want, how you want it to do things
• enriching the tool-set, upgrade your tools, 'pimp my library'
• dropping heavy, cumbersome dependencies, Scala does what Java needs many libraries and frameworks to do
• simple lightweight compile time checked composability and dependency injection
• feature rich actors / message passing, 'free your domain' from pollution, be flexible, scalable

We have measured a reduction in lines of code by approximately one third thanks to Scala's expressive syntax, and the concise nature of functional programming. Our reduction in dependency baggage has led to our deployable artifact's more than halving in size where we are not hooked up to ORM. Perhaps more importantly we have more options at an architectural level, thanks to the capabilities of a more evolved language, and developing and architecting are just more fun, which is an often overlooked side effect of the transition.

All of this, and we can still leverage the undeniably rich JVM ecosystem, all those well implemented frameworks. In short, we can simply do more with less code, and we can do it better.