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.

References:

Brooks, F. P. (1995) The Mythical Man-Month: Essays on Software EngineeringAddison-Wesley, ISBN 0-201-83595-9.

Written by: Stephen Richards
Publication Date:
Last Updated:

Comments

Kai

11 August 2021

Hi Stephen,

Naturally I agree with your comments. A couple of observations, though:
- Using purpose-built commercial software which is already in use by a substantial number of users, and thus has been tried and tested far beyond the initial software development process is invaluable, especially when the results calculated from the software are the basis for decisions worth tens and hundreds of millions of dollars, pounds or euros.
- Nonetheless, there is also substantial value in the actuarial user verifying results and experimenting with the mathematical methods which have been implemented in the commercial software, to gain a greater understanding and develop an intuition for results. Nowadays, the threshold for this is a lot lower than only a few years ago, with expanding open-source software available. In my view, this does not detract from the value of the commercial software, which lies in its reliability, transparency and documentation, but only enhances it.

Cheers!

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.