Thoughts on Inheriting a Financial Model

I see financial modeling as a subset of software development, so software development principles also apply to financial modeling. Here are some quotes that reflects this perspective:

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.
–Edsger Dijkstra

Inside every large program, there is a small program trying to get out.
–Tony Hoare

It was my own experience that made me see the balance between building re-usable models versus building it quickly. I have on many occassions inherited Excel models with many hacks, such as unnecessary parsing with INT(LEFT(“Month 20”, 2)) when a simple numeric value (i.e. 20) could have been entered or stored as an intermediate calculation, multi-line formulas and sheets that attempt to do everything when logic could have been broken up into manageable parts.

I think complex formulas are okay if the intent of the formula is made clear, has a single purpose, and you can easily update the inputs without having to touch the formulas. However, this wasn’t the case. This often happens when you build models under a tight deadline where re-usability isn’t a priority, and later given another (but tighter) deadline because your manager assumes you just need to “make a simple change” to your model.

If your model continues to be useful and expectations keep rising, then eventually you could reach the stage where it’s quicker to rebuild the entire model than to try to understand the model so that it can be changed. You don’t want to reach that stage, that’s why it’s important to refactor your model soon after you meet a new requirement, to ensure that you can meet future requirements in a timely manner.

Leave a Comment