Also the realization of the hardest trick in industry, how to scale :)
Excel works very well for single users with small datasets but if the business works it breaks in various ways. Sharepoint was the solution to scale excel but it didn't seem to have been successful as a tool.
Tons of businesses continue to function with excel without difficulty. Of course if you're shooting for a SV "unicorn" growth curve you're going to leave excel in the dust pretty quick, but a great many businesses in a wide range of industries find excel continues to meet their demands for a lot longer than you might expect.
Out of curiosity. Did it stay that way or did you manage to migrate to another solution? If so, what did that look like? Interested because I’m in a similar situation.
A lot of things fell through the cracks with Google Sheets and Zapier handling everything. I eventually just moved to building a personal dashboard using Next.js and connected with the APIs directly.
Because of excel's swiss-army-knife powers, it will always be present somewhere in most organisations, I agree.
But if you start your business with your stock and order tracking in excel, your customer list in excel, and your accounts in excel, it's not unusual to outgrow excel in some of those areas fairly quickly.
Right, Amazon's inventory system certainly can't be run out of a spreadsheet. But even for something like a very successful restaurant with half a dozen locations across the state, a few spreadsheets often sit comfortably in the middle of it all.
Startups hardly bother with licensing excel/365 these days, and just pop into sheets. From my experience, you don't usually start bringing excel into the equation until you hire that one sales manager that insists on it, or the "Microsoft guy/gal" that just keeps asking "why aren't we using excel?" over and over again.
Or until you're at the scale where you're working with datasets/queries simply too big or too complex for Sheets to handle effectively.
At my current job (late-ish stage SF startup), most of us default to Google Sheets, but there have been enough use cases for "real" Excel alone to warrant setting up Office 365 licensing/accounts and defining a flow for that at the corporate level instead of just one-off licenses here and there.
Our finance team in particular (or at least specific key members thereof) has to use the Windows version of excel because both the macOS version and Google Sheets rapidly buckle under the datasets they're manipulating in their monthly reconciliations. My team has been working on various tools and systems (mostly as extensions to our ERP) to better automate some of these things, but Excel is still a reality until that happens for all their use cases.
> Or until you're at the scale where you're working with datasets/queries simply too big or too complex for Sheets to handle effectively.
At which, again from my perspective and view of things which may be wrong, startups are more likely to automate/productize that so they can better maintain and dogfood it if possible instead of letting someone's Excel workbook grow into a pet ML tool that only they understand.
I think this is where our respective experiences diverge, at least momentarily. Yeah, eventually a company will (hopefully) try to build better tools (as I and the rest of my team are trying to do in our case), but there will be an often-long gap between some employee creating a spreadsheet-based monstrosity and some engineering team turning that into a better tool/system.
I worked for a clearing company that mainly dealt with commodities market and option exchanges. It was a fight to get the individuals in finance to use the software we developed because they would just use Excel with macros. I had even been asked to look at one of the workbooks they were using to fix an error they had been having.
The problem with the software you developed is that they have to give up control. Every change is a change request which needs to be approved and implemented and tested and released.
The upside is higher quality, the downside is way reduced turnaround speed if they need to change something.
I understand why people using Excel are often reluctant to give it up.
Quality often goes down. That request process results in you getting what you ask for, not what you want.
Think about anything that you do in Excel. In what scenario do you roll with exactly what you initially start with?
I just did a preliminary capital forecast in Excel. I could have used something like Google sheets as well, but beyond that, the lack of flexibility makes purpose built solutions less able without specialized people that I don’t have or domain knowledge that I don’t possess.
This. Excel democratizes computation in a way that code has yet to do. If something breaks, non-technical people can just jump in and fix it. If they need new functionality, same thing. They don't have to bring in (or retain) a specialist. That's an incredibly powerful proposition.
>>Tons of businesses continue to function with excel without difficulty.
Without difficulty? No, definitely not. The difficulty is always there, it's just internalized, ignored or worked around in various (often crazy) ways.
Without difficulties induced by scale. Some sorts of businesses will hit scale issues with excel, but many will not.
The baseline difficulty of using excel is not what I'm talking about and I don't consider it relevant since experience has proven that baseline difficulty is not much of an obstacle to real adoption.
Sharepoint was the solution to scale excel but it didn't seem to have been successful as a tool.
I've seen these trends around "Unbundling" Excel:
- Improve UX by specializing UI
- Increase automation with software integration
But given that Excel is acting in the guise of software, doesn't it follow:
1) Running business of Excel has many of the same problems as other software
2) Excel has some key advantages over other software
(By 1), I mean, QA, testing, deployment, etc...)
The article mentions that Excel doesn't need much onboarding. I don't think that's its only advantage. Also, to solve the general software development problems around Excel, one has to match the near-zero onboarding barrier of Excel, otherwise those solutions will get left behind.
Sharepoint had some questionable synchronization corner cases that, in a poorly configured environment, would just lose some people's files. There are plenty of international horror stories where a teammate in Japan checked out a file and forgot to check back in, effectively blocking teammates in Europe and the US from working on the data.
The main advantage of Excel, which leaves us pessimistic on the long-term viability of the niche SaaS solutions, is the "hackability". There's an incredible depth of tooling and market expertise around Excel, from mundane formula structures to macros to addins and COM automation. Thousands of office workers who otherwise have little programming experience are extremely adept at solving problems with Excel.
The SaaS solutions might individually solve different problems, but are not really designed to play nice with each other (nor are they really incentivized to work well together).
That was quite a while ago. My company has been using the O365 for the past two years and it is very reliable, plus you get the full experience and not a half baked Excel such as Google docs(talking about backwards comp, extensions...).
There are plenty of international horror stories where a teammate in Japan checked out a file and forgot to check back in, effectively blocking teammates in Europe and the US from working on the data.
Then don't have people check out files and check them back in. Only programmers like that kind of nonsense! 99% of the time, let people "nominate" a particular copy of the file as authoritative. If something happens to that particular person's copy, let's say their machine gets smashed, then the latest version can be downloaded by their coworker, and an admin can nominate that copy as authoritative. People then go back to the 99% case of just using Excel and saving their file.
The main advantage of Excel, which leaves us pessimistic on the long-term viability of the niche SaaS solutions, is the "hackability". There's an incredible depth of tooling and market expertise around Excel, from mundane formula structures to macros to addins and COM automation. Thousands of office workers who otherwise have little programming experience are extremely adept at solving problems with Excel.
Therefore, a SaaS solution needs to let people do what they've always done, only better. Don't try to make them act like programmers. Don't change their behavior one iota, unless they're getting a payoff of nifty functionality in exchange. As much as possible, just let them act like they've always done.
The SaaS solutions might individually solve different problems, but are not really designed to play nice with each other (nor are they really incentivized to work well together).
One SaaS solution which can solve dataflow and versioning with ultra-low friction could be the one ring to rule them all. All the other SaaS solutions could be built on top of that. The problem is keeping everything super low friction.
FWIW, one of the biggest fast food franchise chains in my country uses a custom Excel sheet as their main backoffice app across the organization. From what I can tell, it's far from a single user app with a small dataset.
Yes, it can be done with a lot of care, but perhaps needing more care than a "real" CRUD application would need. Data normalization, ACID (transaction integrity), indexes, server-side validation, roles (user access levels), etc. take more effort to put into a spreadsheet (or add work-arounds for) than a regular CRUD stack (such as LAMP).
They are great for small projects and prototyping, but just don't scale well unless you want to pay for expensive babysitting.
Note a good CRUD app allows exporting of data to Excel for searching or experimenting with budget scenarios etc., but the "original" data should be in a real database.
The eternal struggle to find balance between spending all your time type checking, compiling, linting, Rusting, testing, unit testing, CIing, etc and actually making working code.
Data normalization, ACID (transaction integrity), indexes, server-side validation, roles (user access levels), etc. take more effort to put into a spreadsheet (or add work-arounds for) than a regular CRUD stack (such as LAMP).
All those things take less effort if you already know how to use Linux, Apache, MySQL, and PHP or Python. If you don’t, but do know how to use a spreadsheet, it takes vastly less effort to do those in a spreadsheet than to learn how to do those with a LAMP stack.
And there are orders of magnitude more people in the latter group than in the former, and their time generally costs much less on the open market.
Which, to be clear, I don’t think is a good thing! Doing those things with a spreadsheet is worse in every way—effectiveness, maintainability, you name it—except this one way. But it’s usually the only one that matters.
My dream, coming soon to an Internet near you, is to “democratize” the things that come easy to us “real programmers”.
The tools to scale excel are essbase or hyperion where excel sheets can all points to a central database/cube of data that can be refreshed and updated centrally and then the sheets can do local analysis and processing; sometimes even pushing data back to the central location (for controled superusers). The finance groups of most fortune 500 companies use these tools.
Excel works very well for single users with small datasets but if the business works it breaks in various ways. Sharepoint was the solution to scale excel but it didn't seem to have been successful as a tool.