I recently went to a talk at the Python for Quants group in London started by Yves Hilpisch, which featured a talk by Mark Higgins, the co-founder of Washington Square Technologies. Mark’s talk was about the benefits of a quant platform, which can help when it comes to working together in a team. The general idea of a quant platform is provide a framework for quants to develop their code in a unified environment, that can be deployed easily to their clients, on trading desks and in other parts of the business. A whole quant environment can be accessed via webpage and run on the cloud (either internal or likely in the future externally). By running on the cloud, it is possibly to have access to lot more computing power, than you would simply running all the calculations locally. Whilst this post isn’t specifically about quant platforms, like SecDB (Goldman Sachs), Athena (JPMorgan), Quartz (Bank of America) and Beacon (Washington Square Technologies), there were many great points Mark made, which are, I think very relevant to how quants do their coding, which I wanted to expand upon here.
One of his key points was that if you’re working in a team, it’s important to use the same code version control system. If you want everyone to work together, it’s a bit difficult if they are also using different code version control systems, which other people aren’t using. He also noted that it’s important that quants in the same organisation to code in the same language(s). Mark extolled the virtues of using Python to do this and C++ for high performance applications. Python also works pretty nicely with C++ and has many great open source libraries (a time saver and helps your budget). There’s also Java, which could be used for where speed is needed (ok, some might disagree with this, but I like Java!), and it’s quicker to code in than C++. Whilst, it might not possible for everyone to use just one language, due to performance considerations (and simply the differences between the task at end being tackled by different quant teams), having a massive cocktail of language creates barriers in an organisation.
There are obvious benefits from using the same language. One is obviously code reuse. The same infrastructure code can be used for everyone. Otherwise, you end up getting a lot of replicated effort for operations, which are needed for all the quants in your organisation. Take for example accessing market data, which quants need for much of what they do. If there’s no code there (in the language you use) already to do this, quants have to spend a lot of time writing low level code to harmonise all the data sources they use. This is one of the reasons I wrote findatapy, to provide a generic interface for Python to access historical market data from many data sources including Bloomberg, Quandl, Yahoo etc. using the same unified code. I’ve made it easy to switch between data sources too. Best of all it’s also open source too! I’m also planning to get it working for subscribing to realtime data feeds too.
Data visualisation is often a key part of communication for quants to the rest of their organisation. It can often take a lot of time, to get this right, if there isn’t already a data visualisation and reporting framework being used in the organisation. I wrote, chartpy to make data visualisation easy, because I became frustrated with the time I was spending doing plots as opposed to the actual number crunching of the market. I’m also in the process of expanding chartpy, to make it easier to develop webpage style reports with it. Again the idea is to abstract away from the low level details of doing a webpage (HTML coding, CSS etc) or plotting, to provide easy high level access for quants to generate reports in Python.
Mark also said that it’s important for quants in financial institutions to code, as opposed to spending all their time modelling. I very much agree with this, quants come up with great ideas and model. Through coding their models can be run by their trading desks and can provide continual information to help them manage their risk. It’s my opinion, that for quants, the software engineering element of what they do, as well as coding more broadly, is just as important as the models they create – software engineering and spending time on software design is not just for technologists! It’s important to ensure that the framework quants use is reusable, to make it quicker and easier to implement new models, so there isn’t a huge delay between developing a model and implementing it. Making code generic and taking a lot of thought to design a framework, saves time, which would be wasted later (albeit overengineering needs to be avoided). There might also be financial models that are used throughout the whole organisation for risk management, yield curve interpolation etc. which can be shared.
CTRL-C and CTRL-V is not code reuse as well! One of the tasks which I do regularly, is to backtest trading strategies, and after a while, I got frustrated with the time I was wasting in redoing parts of my code, which were basically virtually identical in every backtest I did. I built finmarketpy to provide a framework to make it quick for me to backtest new trading algorithms. I spent a lot of time making the code generic and also found it beneficial to use design patterns in the process. Just like chartpy and findatapy, finmarketpy is also available to download from GitHub.
In essence, if quants in your organisation use consistent version control, write in the same languages, work with the same underlying libraries and make their code as generic as possible, they already have a lot of the components in place which are necessary for quant platform, albeit without the bells and whistles.