Spreadsheets, they’re everywhere. Following closely behind email and word processor documents, spreadsheets are possibly the most ubiquitous tool for knowledge workers.
From simple lists to complex financial modeling, spreadsheets are the backbone of how modern business gets done. This isn’t a new phenomenon. Spreadsheets, in the form of VisiCalc, helped kick off the desktop computing revolution.
Many of Apple’s ads at the time for the Apple II featured VisiCalc more prominently than they featured the computer itself:
Spreadsheets were truly revolutionary. They demonstrated to many in the business world that computers on the desktop really could be powerful tools.
VisiCalc took 20 hours of work per week for some people and turned it out in 15 minutes and let them become much more creative.— Dan Bricklin, creator of VisiCalc
Since those days, the spreadsheet has gotten a lot bigger and fancier, but at its core it is still just a big grid of data that is tied together with references and formulas. And somehow, from that basic functionality has arisen one of the most powerful and flexible tools ever created.
Software Engineers and Spreadsheets, Mortal Enemies
To many business folks, “Use Spreadsheets Everywhere” is a bit of a truism. Of course you should use spreadsheets everywhere, that is like saying “you should breathe all the time.” Many hardcore spreadsheet users can’t really understand the disdain for spreadsheets that most software engineers harbor. To have a software engineer say we need to use spreadsheets everywhere is pure apostasy.
But why is that? Well, spreadsheets were the original low-code tool. They provided the everyday computer user with abilities that were similar to those of a programmer. Based on some of the spreadsheets I’ve seen in my day, I’d say they might even surpass the skill of most programmers.
But spreadsheets, unlike most custom software, use the same simple interface for both input and output. They don’t have a complex tool chain or a compile step. You don’t have to “run” your spreadsheet to see the results. When a user “programs” a spreadsheet, the “guts” of the spreadsheet are hanging out for all to see, and the results just show up in real-time. Like magic.
This greatly reduces the complexity of the interaction model on the creation side of things, and allows even the most green computer user to learn how to use the tool from the tool itself. You don’t need to consciously understand programming topics like variables, assignment, methods, references, reactivity, recursion, etc… even though you’re using all of these things.
The user is free to experiment, and iterate, slowly building up more and more complex functionality. The end result is an almost infinitely flexible system where people without a lot of training can create incredibly powerful tools.
And they can also create horrible messes.
Developer, enter stage left
And this is usually where software developers enter the picture. Let me know if this story sounds familiar:
You see, there is this spreadsheet that accounting created. Well originally Bob in accounting created it, then when he retired Susan took it over. Susan worked on it for a few years and then left the company, so it was handed to Tom. When we merged with Initech a few years ago, that business function was moved to a different department and now it is owned by a team of three people.
The spreadsheet got really big and complicated, even though the spreadsheet was now dozens of tabs, so they moved some of it out into other files and linked the files together. For years we emailed the spreadsheet around, but it got way too big, and so now it is stored on a shared drive where everyone can access it.
Over time though, as we put more data into it, the spreadsheet kept getting slower and slower. So a while back we started splitting them up by quarter. So each quarter we create a new copy of the spreadsheet so that we can put new data in there. Unfortunately maintaining all of those copies would be really time consuming, so we make changes to the newer spreadsheets but don’t make those changes to the older spreadsheets.
And finally, with all of these different spreadsheets it became virtually impossible to see data over wide swaths of time. So we created a primary reporting spreadsheet that references each of the quarterly spreadsheets to produce reports so that we can see our overall numbers over time. Each quarter one of us goes in there and adds the lines for the new quarter.
Every once in a while we find that a formula in one of the spreadsheets got changed, or someone just hardcoded a number in. So it is getting to the point where we are having a hard time trusting the data. The whole thing has gotten a bit out of hand, do you think you can help us?
Do you understand now?
Developers get brought in at the end. Simple as that. They never see the spreadsheets that work, or that die. They see the runaway successes. They see the spreadsheets that worked really well, and solved problems for tons of people, and because of that grew into absolute monstrosities because quite frankly they just outgrew the platform on which they were built. (This doesn’t sound too different from “real” software, does it?)
There are only two kinds of languages: the ones people complain about and the ones nobody uses.— Bjarne Stroustrup, creator of C++
Trying to tease apart the logic and functionality in a spreadsheet like that can be a life changing experience. And not in a good way. You end up having to do a lot of tedious reverse engineering to understand how things work. It is a very painful process, and even if you do rebuild this spreadsheet into a bespoke system, you’re now dealing with users who will hate you because you took away how easy and responsive their spreadsheet was. Even if it was riddled with bugs and logic inconsistencies, it’s something they’ve put tremendous effort into and feel mastery using.
At this point, you’re damned if you do, and you’re damned if you don’t.
So you’re saying we should use spreadsheets more?
Yes! The hardest part about building most software is figuring out the process. The power of spreadsheets lies in how flexible they are, and how they allow this amazing iterative process of discovery and a virtually instant feedback cycle. The user just keeps tweaking the sheet. And slowly, over time, it is changed until it does the job it was designed for, is no longer needed, or morphs into something that the original creator never could have envisioned.
This process of discovery was the business figuring out what it needed. Trying to build software from this vacuum would be an exercise in futility. We’ve all seen the scenarios where someone rushes out and buys off the shelf software, or builds custom software. Then when you check in to see how people are liking the new software, you find out all of the users are using… spreadsheets. Why? Because the software didn’t do what they needed, and they couldn’t wait.
However, if they had started with the spreadsheet and then over time moved to custom software, they would have been able to take all of the learnings they accrued and apply them to this new platform. It is so much more likely they would have gotten what they needed.
This is users doing their own discovery in real-time, enabled by the flexible and iterative nature of spreadsheets.
Where do we go from here?
It’s easy to forget that our fundamental value as technologists is not the construction of software; it’s helping our organizations solve problems with technology, in a responsible way that balances short-term and long-term needs.
If we embrace spreadsheets and show users we understand the appeal, maybe even offer to help, we can intervene at key moments – after the spreadsheets have proven their value but before they’ve grown into monstrosities. Our stakeholders will trust us more when we tell them that we appreciate how far their spreadsheets have taken them, but now that the path is well worn, it’s time to consider whether efficiencies can be gained from a more robust platform.
Every time you create a spreadsheet, think about this quote:
You either die a hero, or you live long enough to see yourself become the villain.— Harvey Dent, Two-Face from Batman
So the next time someone complains about spreadsheets and how terrible they are, tell them they have no idea what they are talking about. Spreadsheets are wonderful things, and we should start with them wherever we can, and kill them when it makes sense.
Now go forth, and use spreadsheets everywhere!