Why Excel Excels
Microsoft Excel has always struck me as a great tool for dealing with data. It lets us manipulate data in a transparent, predictable way, which makes Excel extremely easy to use. It’s no coincidence that being a spreadsheet whiz is a prerequisite for a job in the financial sector.
What’s obvious to any practicing programmer, though, is that the core of Excel (i.e., excluding macros) isn’t that powerful. All these bankers could be doing a lot more with their data if they knew Python, right? What gives?
Fine, learning a programming language is hard, especially for people with non-software backgrounds. I get that. But at some point, the institutions that run Excel on thousands of computers must have noticed the benefits of using Python (or another language that’s easy to learn — Ruby and VB come to mind) for their work. I think the continued choice by business professionals of all stripes to rely on spreadsheet software so heavily for basic computational needs reveals something about the very nature of spreadsheets. Maybe there’s a certain elegance at the heart of Excel that makes it so appealing.
Maybe it’s not about what you can compute. Maybe it’s about how you compute it.
In programming terms, Excel essentially gives us a huge (2²⁰ rows by 2¹⁴ columns) 2D array, where we can set each entry to be a number, a string, or a function (“formula”) of other entries in the worksheet. Moreover:
- Functions are pure. They have no side effects on other cells, only returning output for the cell from which they were called. They’re also deterministic (consistent output for the same input).
- There is no available storage for data other than the 2D array entries (cells). In other words, no arbitrary variable declarations.
When we view Excel through this prism of programming language features, we see it for what it really is: the application of the functional paradigm to an intentionally limited data structure.
The appeal of the functional paradigm in Excel can be explained in the same way that the hype around React and Haskell can be: functional code is more predictable (easier to maintain) than code with side effects. In Excel, the output of a formula has the same beneficial qualities. As a result, “programming” using Excel formulas doesn’t even feel like programming in the first place.
The data structure (2D array) is just the best abstraction for what Excel was originally intended for: digitized, interactive versions of what used to be tables on paper (e.g., balance sheets, cost schedules). Using a single global data structure also boosts predictability by lowering the cognitive burden on the user. Instead of dealing with variables and storage, the user simply refers to a labelled cell.
A side effect of using a 2D array or “grid” is that the user can model the spreadsheet in their mind literally as a sheet of paper. This makes Excel great not only for running computations, but also for presenting the results. Charts and PowerPoint make this extremely accessible.
The upshot is that Excel is just constrained, domain-specific programming. The business use case for Excel remains strong not only because it has developed a large repertoire of features (like macros and charts and so on), but also because it is an abstraction of programming that incorporates functional philosophy and a global data structure. These aspects give us a product that runs predictable computations, is easy to use, and backs data-driven presentations.
The lesson of Excel: instead of implementing the typical over-engineered solution, extract its best parts for the problem at hand, and burn the rest.
When we’re stranded on an island, surrounded by the unknown, we’re tempted to build the greatest, most resilient boat that ever was. Excel is the one who shows up and wisely suggests a small raft.
If only we could say the same about Windows, who suggests a spaceship.
Follow Ideas and Words using the button below for more like this!
