Consider a Career in Actuarial Software
By David P. Friedlander
Looking for a change in direction? Software may be calling your name.
Half of my job as a chief actuary at a software company is to help design software that complies with the Actuarial Standards of Practice and the applicable laws and regulations. Then I have to make sure the end product is in accordance with the designs. The other half of my job is to train and support the software users.
Today, nearly all actuaries use computer software and most use software tools that are designed specifically for actuaries. Some are at least partly designed by their fellow actuaries. However, actuaries are also frequently involved in the design of software tools that are used mainly by non-actuaries. If you’re an actuary who enjoys working with computers, this could be the career path for you.
Communication Skills Are Key
My own firm is always looking for the few people who have that elusive combination of actuarial, communication, and technology skills that make it possible to work smoothly with both the technology who actually develop the code and the clients who use it. For our company, those end users are employee benefits professionals. However, other software firms that employ actuaries produce tools used by life insurance actuaries, casualty actuaries, underwriters, and others.
Those of us who work with software firms find ourselves both training and supporting the actuaries and actuarial assistants who use the software. These people are usually well versed in actuarial principals but often know very little about computers. We also need to provide design specifications to technology professionals who know far more than we do about computers but may not know the difference between an actuary and a mortuary. Therefore, we need all of the communications skills that a consulting actuary needs as well as an understanding of computers.
In order to communicate actuarial principals to technology professionals, we need to have a very thorough understanding of those principals. It’s the same kind of understanding required to pass actuarial examinations, although, unlike some other environments in which actuaries work, software firms usually consider the quality of their work much more important than examination-based credentials when they judge their employees.
A software product has to anticipate many different scenarios, some of which probably were not included in the limited number of questions that could be included on an examination. For example, a product that calculates optional forms of pension benefits has to account properly for the participant whose benefits are the regulatory maximum benefit under the normal form of payment but not under the selected optional form and vice versa. On the other hand, it also has to account properly for the person whose benefit is so small that the option isn’t permitted at all, along with the vast majority of cases that fall between these extremes.
As an actuary who has been in the software development environment for 30 years, I’ve witnessed incredible changes in the data processing environment. In this field, the one thing that’s certain is change, so one has to be very flexible.
In the 1970s, almost all actuarial software resided on mainframe computers, often the so-called super computers (far from “super” by 2005 standards) that were manufactured by the now defunct Control Data Corporation. In those days, programs were laboriously created on punch cards, one instruction per card, and woe to anyone who dropped one of those decks if the cards weren’t properly numbered!
By the early 1980s, much of the software had migrated to mini-computers manufactured by other poorly remembered companies such as Prime Computing and Digital Equipment Corporation. I still remember authorizing a purchase in 1982 for a 300 megabyte disk drive that was the size of a desk, had a removable disk platter weighing more than 50 pounds, and cost about $20,000. (Today, a $300 MP3 player has 100 times more disk space, fits in my shirt pocket, and weighs 4 ounces.)
Later in the 1980s, the tools appeared on DOS-based personal computers. Of course, personal computers still dominate today, although DOS is nearly forgotten and has been replaced by various versions of Windows. Each of these advances, along with the well-known changes in the regulatory environment, has required that the software tools be largely rewritten and, therefore, has created new opportunities for those of us in the software development field.
In addition to these changes, the tools themselves have become far more complex, so that it now requires a team of technology professionals to write the actual code. By comparison, as recently as the 1980s, actuarial software firms were often staffed entirely by technology savvy actuaries and employed few or sometimes no technology professionals. In those days, all that was expected of the tools was that they produce the correct answers. Output didn’t need to be attractive because it was manually transcribed before delivery to the end user and nobody expected results to arrive in less than an hour.
Today, we expect instant results that can be conveyed to the end user and with almost no work to be done by the operator of the tools. We also expect everything to run remotely via the Internet. What all this means to actuaries who work at software firms is that we have to communicate our science to technology professionals instead of write code. Communications skills have become more important to us than programming skills.
None of this means that anyone can work at a software environment without understanding data processing. We still have to know how to write programming specifications that are acceptable to technology professionals, and this requires an understanding of database technology. Modern databases are accessed using a tool called SQL (sometimes pronounces as Sequel) and it’s very helpful for actuaries in this environment to know that tool. It’s also very useful to be able to read and “debug” actual code and even to be able to write small patches of that code (often referred to as “entry point programming”).
Breaking the Code
Programming code is written using tools called programming language, so these skills require a familiarity with those tools. The most modern code is written in the following languages: C++, C# (pronounced C-Sharp), DELPHI, Visual BASIC, and FORTRAN. However, we often also have to work with older code that can be more economically maintained than rewritten. This code is also written in FORTRAN, BASIC (the predecessor of Visual BASIC) and PASCAL (the predecessor of DELPHI). However, it may also be written in dying languages such as COBOL and APL, so it’s useful to know those too.
It’s also worth noting that the majority of actuaries who work in software development companies are either enrolled actuaries or associates of the Society of Actuaries or the Casualty Actuarial Society, rather than fellows of those organizations. Because it’s one of the areas in which an actuary can work without passing as many examinations, the extra time we spend learning about computers may be at least partially offset by fewer hours of formal studying.
To summarize, working at a software company is a choice to consider if you’re a strong technical actuary with excellent communications skills, you’re able to deal with frequent changes to the environment in which you work, and if you enjoy working with computers and know more about them than most of your fellow actuaries. It’s an option that may not require completing all of the fellowship examinations if you have technical strengths that offset a lack of credentials.
David P. Friedlander is principal and chief actuary at Lynchval Systems Worldwide in Chantilly, Va.