Électricité de France - Alex McGuire

Alex McGuire talks about his experiences at Électricité de France Trading (EDFT) [1] as Team Leader for the group developing applications for energy derivatives trading and pricing. He explains the benefits EDFT has gained by replacing a substantial part of their 300,000 lines of Java code with Scala. Alex, a mathematician and former options trader, has over 15 years of development experience creating financial trading applications.
 

Why did EDFT start using Scala?

Alex: Perhaps I need to tell you a little of what EDFT does so you can understand the context. In the past EDF produced power to meet their consumers demand. The problem was essentially one of forecasting demand and making sure you had enough capacity on line to meet it. When the energy markets were liberalized companies like EDF did not have to be so strict about meeting power demand, they could always buy power from somewhere else. So power became a tradable thing. You could sell future capacity to other companies or set up contracts to buy future capacity for given prices. EDF is a very innovative company and saw how this could lead to much lower cost and better plant utilization. It often comes as a surprise to people that a company like EDF trades power using financial instruments in the way that you or I may trade such things as stocks, shares or bonds. As a power producer you could agree a contract with another company to provide 100 Mwatts for a given price in 10 months time. They could in turn sell this on to other companies. In all these trades no actual power production has yet taken place. Only futures have been traded. By doing this we are in effect balancing supply and anticipated demand across many suppliers.

The trader group at EDFT take the real assets like coal or oil based power stations, gas storage units, hydro electric dams, emissions contracts, just about everything related to energy, and try to model them as financial products rather than as physical things. This gives a whole new dimension to power delivery. EDFT monitors the power market and decides when EDF should generate power, sell it or buy to fill shortfalls in capacity. Sometimes, for example, it is cheaper to buy power on the market and turn a power station down or off, or leave the water in dams because it will be more valuable in the future, perhaps in as little as a week or two, or even several months later. Every asset has its own unique features, so we support a variety of exotic complex options and each one needs to be modelled and priced.
 

How do you do this?

Alex: At EDFT we developed models using sophisticated Monte Carlo analysis to set prices that maximize the option values in what is a complex multi-variable problem. As you can imagine there are many influences on power generation and the models are valued using a grid with hundreds of cpus to be able to correctly reflect these subtle interactions. The models have been refined over the past ten years and are now embedded in Bluebird, a system we wrote to support the Trader pricing. There are some 300k lines of Java code supported by seven developers. It is now a mission critical application and in continuous use by the power Traders and management.
 

What about Scala?

Alex: Ten years ago when we started writing the application we knew Java was a much better bet than C++. After all managing memory just shouldn't be the job of someone trying to get their head around pricing exotic options. So we jumped into Java and have been very successful because of it. However, the verbosity of Java has become a growing annoyance. People complain about excessive use of parentheses in Lisp but Java requires so many just to keep the compiler happy. Then there is all that boiler plate you have to write. Most of the group are into languages so we had been looking at all sorts of alternatives, Lisp, Smalltalk, Pizza, Groovy and Ocaml. We were looking for something to improve our programming experience. We tried them for small projects and Lisp was quite a good fit to our problem, however the lack of transparent interoperability with our existing codebase was an inhibiting factor. Then we came across Scala. It was just fantastic!

The team was into Open Source tools and picking up Scala was really easy. We are all from different backgrounds and consequently have wildly different programming experience. A couple of us had had mathematical training and Scala was just night and day when compared to Java. The rest of the team were all excellent programmers so they made the transition from Java to Scala quickly too. At the time we were frustrated by the lack of a decent IDE. However, we found the Scala Eclipse plug-in and got started. It was soon apparent that it was just not up to the job. Not enough features and unreliable. We hired Miles Sabins' company, Chuusai, to add the features we needed and improve the reliability. This worked out well and we could soon focus on getting Scala code written. Now we use Eclipse and Intellij. They are interesting to watch. Sometimes Eclipse is ahead and then sometimes Intellij. The competition has obviously been beneficial as they are now both very usable products.

We started by moving non-critical components of the application over to Scala. Then as we got confident we just wrote all new components in Scala. Of course there is still work to be done maintaining existing Java modules, so the transition is still ongoing, however the large majority of all new work is in Scala. I personally haven't created a new Java class in over six months. We currently have about 20k lines of Scala and a gradually shrinking base of legacy Java. 20K lines may not sound like a significant percentage of a 300K line system, but the equivalent Java code would be more like 50-60K lines. One of the really nice things about Scala is that you can mix and match it with your old Java code. You can manage risk very well.
 

What do you think of Scala?

Alex: Well it just looks like Java should have been. For me, my personal pleasure was having closures. I had really missed these in Java. Learning the full potential of the syntax takes a while but pays off. In the early days I would write what I now see as many lines of ugly Java look alike code. The same thing I now would write in a couple of lines of Scala. But this is not a problem. I think everyone will start writing Scala in whatever style they came from, C++, Java, Lisp or Haskell. The important thing is that you can, and be getting stuff done. In the group there is always a bit of competition and you soon pick up the new concepts. I came from the functional programming background and had used quite a few of the features already. Pattern matching in ML, closures in several languages, traits reminded me of Ruby mixins, OO from Java and so on. But Scala brings it all together with features like type inferencing to make a very practical language, and it runs on the JVM. Productivity goes up and we have found the code is a lot shorter. My guess is about one third of the equivalent Java code length.

I found the book on Scala is a great read. I almost read it from cover to cover in one sitting, but it is not good for reference. The index is incomplete and so many of the language features are hard to find. Although there is a lot of interesting material in the book, a programmer with no functional programming experience at all may find it helpful to read the first few chapters of the classic 'Structure and Interpretation of Computer Programs'.

We write a lot of matrix manipulation code and it looks like maths. That's neat because it's easier to understand. The simple ability to overload operators such as the plus and times symbols makes things so much more readable. You can express the matrix manipulations directly a+b*c and so on. You could say my favourite DSL is maths.

Since the inception of the Bluebird system we have done maths using quantity objects rather than doubles wherever possible. This was to avoid all sorts of trouble with mixing units like megawatts, barrels, tonnes etc. Although this made our code much safer, in Java it led to code that was ugly and difficult to read. For example '(price.minus(strike)).times(power).times(hours)'. With Scala's implicit conversions we could replace these expressions with the natural looking '(price - strike) * power * hours', and this could be done without the need to rewrite our Java Quantity class. We were initially nervous about the time cost of the implicit conversions as many of the models have tight iteration loops. However benchmarking showed that the compiler was doing a great job and the overhead was negligible.

The only part of Scala that I personally find little use for is what is, to me at least, the more theoretical section on types towards the end of the book. Perhaps this due to my background with more dynamically typed languages, but I can see its use for people writing things like collection libraries. For the moment I am happy to give it a miss. In any case, unlike Java, I rarely find its type system a hindrance.

I wouldn't describe myself as perfectly fluent in Scala yet, but the process of discovering how to write more idiomatic code has been an enjoyable one. In some cases I am confused whether to use curly or regular braces, so still something to learn it seems.
 

How did other people take to Scala?

Alex: Some people view programmers as translators, you know the idea. The user has a requirement that they discuss with a business analyst and they write a specification for a programmer who translates it into computer programming language. I think by taking the analogy with human languages too far, the difficulty of finding 'speakers' of a particular language is a reason some companies avoid becoming early adopters of newer languages. I've never believed in this model. Good programmers tend to think in terms of abstractions, and should be able to program these in any number of languages. The choice should never be 'which language do you speak', but rather 'which is best for the job'. So when we recruited we simply looked for good programmers with experience in several languages and they make the transition into Scala easily enough. We had the classical philosophical debates about what Scala can do versus other languages. The key question in the end is "What does it make easy?" You can do anything in most languages but many common things are just not easy or pretty in many of them.

For example, the Java collections make things so hard in comparison to Scala. Then there is the Scala "for" syntax which is so elegant. It was well thought out syntactic sugar. The conciseness means I can see more of a program on one screen. That makes code so much easier to write and browse. You can get a much better overview. For example when I have some mathematical model to write with Java I have to keep two models in my head, one the model itself and the second a model of how to implement it in Java. With Scala like Lisp or ML the programming model is so like the mathematical one that one model will do. That gives cleaner code and fewer errors due to moving between two models in your head. That's a big win, much more productive.

Tomas Rynne was the first person in our group to say that he was not creating Java classes anymore. He is a very experienced financial systems developer who came from a liking for Smalltalk.

Another in the team, Lee Momtahan who is giving a talk at the Edinburgh at the CUFP 2009, would prefer to write in Scala with Emacs rather than Java with a great IDE. He has been a heavy user of the parser combinators to improve the Trader interface by creating a DSL to describe financial derivatives. It allows traders and structurers to quickly describe new options and value them via the modelling system. Previously we would have had to write anything up to a thousand lines of code that was used once and thrown away. Now the Traders can create a description of their financial option in the DSL, internally called Diesel. Well we are in the energy industry! The DSL combinator parser turns these descriptors into objects that can be used directly in the Monte-Carlo analysis. The traders think it's magic. They can turn around new pricing ideas quickly. Mostly we like it because we do not have to do tedious repetitive one shot coding.

Here's an example of Diesel:

:VOLUME = 1063000 MWH;
:STRIKE = 20.05 EUR/MWH;
:PREMIUM = 3.73 EUR/MWH;
:F = AVE(:M =JAN09..DEC10;
                AVE(FUEL_OIL_1PCT_FOB_ARA_CARGOS, :M) *
                AVE(1/ECB_USD_EUR, :M)
        );
:G = AVE(:M =JAN09..DEC10;
                 AVE(GAS_OIL_0_1PCT_FOB_ARA_BARGES, :M) *
                 AVE(1 / ECB_USD_EUR, :M)
        );
:P= 0.0264 TONNE/MWH * :F + 0.0313 TONNE/MWH * :G;
CALL(SWAP(:P - :STRIKE, 06JUL09), 30JUN09) * :VOLUME 
         - PAYMENT(:VOLUME * :PREMIUM, 16DEC08)

 

Did you have any resistance to Scala?

Alex: Getting into Scala we had to climb over a few political hurdles. We had a technology review from an independent group. They raised exactly the same issues that I faced when I decided to use Java twelve years ago. New technology, unproven, long term support risk and so on. After several discussions the management team assessed the risks and supported our decision to go ahead. Great decision and it really paid off.

There were no programmer issues. After a week we felt more productive as a programmers in Scala than we already were in Java. It just helps you in so many ways.

We have about 300K lines, working on this base for the last ten years but the size stabilized about 4 years ago. There are about 20K lines of Scala and this number is growing. We interface to a lot of old Java code. Now half the team are almost pure Scala programmers, and I exepect this fraction to grow. Of course, there will continue to be work for some time maintaining the Java parts of the system. If we were starting from scratch today we would write it entirely in Scala but it a complex stable application so we are happy to keep some parts ticking over in Java for the near future.
 

Do you have any advice for Java developers moving to Scala?

Alex: It's not very hard for a typical Java programmer to become a proficient Scala programmer. You can begin by writing Scala in a very Java like style.

You can leverage your Java knowledge to get into Scala. Take snippets of code in Java and move them into Scala. Just do what comes naturally using the Scala syntax then once you are comfortable and productive start introducing Scala syntax and functional programming techniques, like filtering and maps using anonymous functions etc. Things like the "for" are just so likeable that it does not take a good programmer long to grasp the fact that scala is neat and they just go looking for the features they need. The whole process can go very quickly indeed.

We picked up Scala about two years ago and it really works for us. So I would just say get a book and start coding!