As I am diving deeper and deeper into my effort to brush up my coding skills from where I left in with a Computer Science degree in 1992, I am surprised by how difficult it is to interpret code. Yes, coding languages have become very “compact”: a simple expression can do incredibly things: define an object that returns a function which in itself returns an array objects where each property is again a function. The language is incredibly efficient, but it takes some head scratching to understand it. A bit like the English “42” is a shortcut for a more elaborate explanation of the meaning of life.
There is a parallel here to building Excel models. I have probably spent a good part of a decade building financial models that value companies or evaluate strategies. You can also be very efficient in Excel:
- Putting very long and elaborate formulas in just one cell saves you a lot of rows with subtotals and other intermediary steps of calculations
- Using advanced Excel functions that calculate a value for you as a black box
I never used any of the above for these reasons:
- Errors, for example including the first row of your spreadsheet with the years (1993, 1994, 1995…) into your cash flow. A small mistake can make your model of by a few billion dollars.
- Changing models the next morning. If everything is spelled out it is easy to add a market, a scenario, change an assumption
- Changing models six months later, elaborate models are much easier to understand.
- An elaborate model makes it easy to spot other interesting insights, why valuations are different, and what actually makes the difference, and what is totally irrelevant.
When it comes to Excel programming, I am pretty confident that my approach is still the right one and I will continue to study coding to see whether my hunch is wrong.
Cover image by Mateusz Delegacz on Unsplash