Buy versus build

If you are in the business of pricing and managing longevity risk, you need software to help you perform your analysis. You have two choices:

1. Buy in software purpose-written for the task, or
2. Build the software yourself.

We have been in the business of selling the software in (1) since 2006, so I fall somewhat short of being a disinterested commentator.  However, regarding (2) I recently rediscovered one of the seminal texts on software engineering, namely "The Mythical Man-Month" by Frederick P. Brooks.  Here is what he has to say regarding the decision above:

The most radical possible solution for constructing software is not to construct it at all [...] Even at a cost of $100,000, a purchased piece of software is costing only about as much as one programmer-year.

Brooks (1995, p197)

The above argument is economic, and focuses on the direct programming costs.  However, there are also indirect costs — you cannot expect professional programmers to craft mortality-analysis software on their own, so you will have to assign at least one actuary at least part of the time to the project.  That actuary's time also has a cost.

In addition to the direct and indirect costs of a self-build, there are also opportunity costs — while she is supporting the programmers, the actuary you assigned isn't doing other actuarial tasks.  Brooks also notes that people tend to underestimate how long it takes to create software, so there is a lot of value in the time saved from buying pre-written, pre-tested software:

And delivery is immediate!  [...] Moreover, such products tend to be much better documented and somewhat better maintained than homegrown software.

Brooks (1995, p197)

To this I would add that there is an unstated assumption that the self-build will actually work.  As a counter-example, we know of one insurer that attempted to write its own software for survival models based on our published papers.  After a while the project was canned...and the insurer has been a client of ours ever since!  One reason for the self-build failure was the nature of the challenge:

[Mathematical software] is arcane, requiring an enormous intellectual input per line of code [...] The cost to reconstruct a component of mathematical software is high, and the cost to discover the functionality of an existing component is low.

Van Snyder, quoted in Brooks (1995, p223)

Van Snyder was actually writing about software re-use, but we can regard software purchase as a very specific example of re-use.  And could there be a better description of actuarial mortality-analysis tools as "arcane mathematical software"?

So, should you buy or build your mortality-analysis software?  Before making a decision, I recommend dipping into Frederick Brooks' landmark work.  It will be time well spent, whatever you decide.