What actuaries can learn from developers

It’s no secret that actuaries do a reasonable amount of coding throughout their working life; most of which is used to setup and maintain actuarial models for a range of tasks eg. valuation, regulation, strategy and pricing.

But actuaries aren’t software developers. They of course have mathematical knowledge and logical minds that are well suited to coding, but they lack the training and strict methodologies that allow good software developers to write great code. Just as actuaries go through years of training to learn the mathematics and practicalities involved in their role, programmers go through years of training to produce good quality code that does what it needs to do, is transparent and maintainable.

The good news is standard coding practices that professional developers use could be extremely valuable to actuaries, and they certainly have the ability to learn them. The issue is though, the tools actuaries use often don’t make these practices possible.

Here are a few key practices that can hugely improve actuaries’ code:

Peer review

One of the biggest coding issues for actuaries is that they’re often working in isolation, testing to see if their code works based on the results it produces. But one of the cornerstones of good development processes is collaboration, especially peer review of code changes and outcomes.

If the results look fine, why should you do further checks? Regression testing (Comparing results with previous versions of the code, to make sure that any changes in results are not unexpected) gives comfort that code works for the cases in the input, but what it doesn’t do is guarantee that it works after any changes.

Policyholder profiles, products and assumptions change over time and shortcomings of the new code won’t be picked up for combinations not present in the current input. That is why developers apply peer review and unit testing (see under testing below): to future-proof the code for all possible cases that may be present later.

On top of this, with a lack of code peer review, a model will become harder and harder to understand and work with as different actuaries add new functionality in different ways. The risks of errors creeping in will increase significantly.

Unfortunately, the most common actuarial programming tools, such as Prophet and Excel, don’t make it easy or possible to keep track of changes by multiple people over time. This means it’s very difficult to understand when certain bugs are introduced, and how to merge different versions from different people over time. The result can be, for example, a proliferation of different versions of Excel files, where nobody has a clear picture of which version does what.

Developers, on the other hand, tend to use some of the many tools out there specifically designed for code collaboration and review, such as Pivotal and Github. These tools allow teams to track and merge changes while multiple people are working on an application, saving them from these potential issues.

Documentation

Another key factor in good development is documentation. A large amount of coding done by actuaries happens as and when needed. Very little thought is put to correctly documenting the code or leaving it in a state that will be helpful for the next poor soul to stumble upon it. This is how companies end up with large, messy, undocumented code that no one but the original author has a chance of understanding.

The lack of proper software development tools and processes means you end up with what is called a "legacy" problem: someone inherits code that is all but impenetrable, and with no tools to test or safely make changes. This usually means that nobody touches existing code (because touching it means it will fall apart like an unstable Jenga stack). Instead people work around it, adding new code on top of existing code (again, like Jenga). This makes the code base harder and harder to maintain.

Unsurprisingly, a lack of documentation means you are living with a huge key person risk. What happens if an actuary gets sick, leaves the company or goes on holiday? If any code that they worked on breaks, who’s going to fix it? Will they have to figure out how it works from scratch? Undocumented code can become an expensive problem very quickly.

Testing

Finally, testing is essential. As mentioned earlier actuaries generally only use regression testing, which although useful can create big issues when inputs change. For this reason, developers would also do unit testing.

Unit testing (well, any testing) acts as a safety net for change: when you refactor code (rewriting code to improve the structure and quality), the tests will guarantee that your new code will do the same thing as the old code.

At Montoux, our unit testing code is around the same size as the code for our application. This means that when we run tests we know exactly what breaks and where. Without unit testing you are essentially just crossing your fingers and hoping that when different types of assumptions and policyholder input are introduced, the model still works.

Implementing good development practices could save you from a lot of those potential problems. Implementing a type of peer review for example, if you have more than one person writing code, could be a good way to check the quality of your work. Unfortunately, it’s still difficult to automate tracking in the tools most actuaries are working in, but improving the documentation of your code would be a good first step.

These tools, which require a large amount of customization and coding, are holding actuaries back. You need to work harder just to make them fit requirements, when you could be producing better insights for the business instead. Unfortunately that is the case with the majority of pricing tools that currently exist in the market.

Using a preprogrammed and highly parameterisable tool instead would mean that coding is done by specialist software developers. That would take away a huge amount of risk and time wasted just making models work, allowing actuaries to focus on what they should be doing, which is adding insight.

About the author

Gert is CTO and co-founder of Montoux, senior software developer and an expert computer scientist with over 15 years of experience with software development and system administration. Absolutely dedicated to the integrity and quality of the Montoux platform, Gert holds sway over Montoux’s team of spirited PhDs. He makes sure the wheels keep turning smoothly behind the scenes, seeking ever to refine the functionality and user experience of Montoux’s products.