I showed Krazam video to my wife few months ago, she's pretty excellent at Excel, omg we both were rolling around on the floor at the impactful conclusion. Brilliant!
Is it impossible to dethrone Excel? I feel like almost every SaaS space is heavily inundated with people trying almost every angle to rethink every data visualization and manipulation program, except for the straightforward spreadsheet. Google and Apple with Sheets and Numbers haven't seemed to make any genuine attempt to improve on Excel. I'm aware of Alphasheets which seemed to fizzle out and get acquired, am I missing someone else or is doing a spreadsheet startup just not that exciting?
If your application cannot open a 15 year old spreadsheet full of arcane VB code and "just work" then no serious business will ever adopt you. It's easy to make a spreadsheet app, it's not easy to make one that will work with the insane amount of legacy Excel code that's out there. It's the same reason why there aren't web browser startups.
Our production planning department subverts our erp system via excel spreadsheets that they distribute it has all the problems you'd expect.
I looked in horror the first time I gazed upon this thing. The guy who created it hates it and realizes it's a gigantic crutch, but the will to move off of it is a intracompany political land mine.
I frequently see programmers bemoan Excel-driven business processes, but what is the alternative? Requesting development support for a process used by five people will 1) never be prioritized and forever be on the backburner 2) even if it is ever done, it will not work correctly and getting updates done will require moving mountains for a second time.
In contrast, everyone knows Excel and an intern can make changes.
Correction: Everyone thinks they know Excel and even an intern can make breaking changes.
Excel highly encourages what would be considered insane development practices anywhere else (copy-paste code, single-character variable names, no version control, mixing code and data, mixing front-end code and back-end code, no unit, regression or integration tests, development on live systems). As a result, any nontrivial Excel spreadsheet end up being far more brittle than the same solution coded up by even a well below-average coder. Sure, maybe with extreme discipline these can be avoided, but Summer Intern Derek doesn't have said discipline.
The thing is: The knowledge is in understanding the business and business process. The ones who grasp that know Excel good enough to build a solution, which works for them (especially as they also know the builtin assumptions and limitations)
Transferring that knowledge to a software department (and then limitations back) is quite complex and fails more often than not, leaving the business side with a software they don't want to use and can't adapt and quickly go back to Excel ("I understand it! I can adapt it!") and use the official tool only where required with hesitation.
And yes, the Excel tool reaches a messy point, but it's built over years step by step, tied to the process changes.
Indeed, enabling people to become self sufficient for solving problems with data was one of the main things that propelled the personal computer revolution in the first place.
What I have watched in a quite well known Lifesciences company, is that some of those people eventually outgrow Excel and get the IT department to install VS for them, and they happily continue with VB.NET.
I work at a (imo serious) company that runs mostly on Google sheets (since the beginning) and I don't believe we have much need for opening ancient Excel files.
Do you think you have equivalent Sheets lock-in where any product without Sheets' feature set would be unable to compete? Or is your company one that doesn't need much out of a spreadsheet and could pivot to a cool new competitor?
My assessment here is only shallow, but I think we could migrate to any tool that has a comparable support for scripting. It wouldn't be a dealbreaker if we had to rewrite the scripts again.
However, it is much more probable that we would migrate some processes to self developed specialised tools rather than another Google Sheet alternative.
The hardest unsolved problem is document compatibility. It's not enough to have a cool tool -- you need to be able to interchange data with existing users of Excel and other workflows. This was an important piece during Excel's journey to overtake Lotus 1-2-3.
We (https://sheetjs.com/) have been looking into document compatibility for 10 years (celebrating our 10 year birthday this week!), and our eponymous open source project https://github.com/sheetjs/sheetjs is used by companies large and small. It's not a particularly glamorous subject and doesn't tend to electrify people in the same way as build tools or frameworks.
.
There are ways to improve upon the space, but the problem is that the world has changed. Excel was designed to be the "center of the universe", a creative substrate that bypassed org security policies and enabled extremely flexible line of business tools. Excel was designed to be used by one user at a time, with fundamental inconsistencies blocked at the UI level (for example, try entering a bad custom number format). This made sense 20 years ago, but it doesn't make as much sense now.
The current crop of SaaS companies effectively monetize access to the data. They aren't incentivized to make it easy to export metadata back to Excel -- they want to keep you using the software. This runs at odds with the data portability and freedom that is needed for a successful replacement.
Whatever will replace Excel won't be a facsimile of the current tooling (what Google and Apple are trying to do), nor will it be a siloed experience (what the myriad of SaaS apps are trying to do).
1) Excel just has a fucking ton of features, it's really hard to compete with a product that is responsible for at least $100 billion of Microsoft's value as a company. Any competitor tries to convert Excel spreadsheets but is always missing one or two things.
2) There are a bajillion Excel documents out there that people need to interoperate with, but I think this is less important than (1)
3) Microsoft sells their products as part of a huge bundle, so any one Microsoft product is essentially "free" when compared to the alternatives. This is the toughest nut to crack. You make a better Excel. Well, OK. Your customer is already paying Microsoft $xx/user/month for Word, PowerPoint, Teams, Windows, Active Directory, etc, and that won't change if they stop using Excel. But now they gotta pay you... not a really attractive proposition for them.
There’s Inflex [0], which has a very interesting (and I think better) approach to spreadsheets. I’ve also been working independently on a very similar idea [1], though it’s early days yet and I’m still busy figuring out the how to build it in a principled way. The Inflex website also has a really nice bibliography [2] with a fairly complete catalogue of what else has been done in this space.
The problem is that excel is a lot of things packed into a single application and the attempts I have seen at challenging it typically only consider one usage.
for some people, it is a tool to:
- just to format a table to be printed
- visualise and analyse large amount of data (pivots, chart)
- store data (like a database)
- make complex calculations (financial modelling or else), which can go from a quick, one off throw away calc to an established critical process
- automate tasks (VBA - more often that not with close to zero programming skills)
- just a convenient UI to edit data (I often use .xlsx as configuration files when a script requires lots of mapping to be maintained by end users)
I have seen lots of attempts that address one or two of those points. But all of them at once?
First you have to know all the things it's used for, and possibly even Microsoft doesn't know. Short of that, you have to duplicate all of its functionality. You can't follow the 80-20 rule if you don't even know the 20. I think this is also one of the causes behind the Second System Effect.
> every SaaS space is heavily inundated with people trying almost every angle to rethink every data visualization and manipulation program, except for the straightforward spreadsheet
Excel killers may be the most common start-up idea after dorm delivery.
I'm not sure we need to replace Excel. Just need to just stop using it for things it wasn't designed for and isn't good at.
<Obligatory Bart Simpson writing "Excel is not a database" cartoon>
Airtable does a pretty good job of combining elements of spreadsheet and database in a package that supports collaboration. It's not going to replace Excel though.
It's caught up but, Numbers and especially Sheets worked much better than Excel for collaboration until recently. Sheets is still the best here in my opinion.
Aside from that, Sheets is easier to use for pivot tables. Numbers has one underrated killer feature: independent tables with independent formatting on one screen.
But none of that matters because excel is just the de facto standard, and it's really hard to grow a company to a certain size and not end up with having Office licenses for everyone.
Does anyone know any good resources describing how the spreadsheet software is actually built? Especially the part where formulas are written using column and row numbers but when columns/rows are added or removed, formulas are updated and remain in sync?
One facet of the apparent complexity comes from the fact that Excel's default "A1" cell indexing style is actually a facade for "R1C1" style references, which can express relative cell coordinates. A column of identical R1C1 references appear to change when you add or remove rows and columns around them because they're being shown as A1.
This, and updating of values when a cell is updated. Formula evaluation is based on a directed acyclic graph. If a node on the graph is updated, everything "downstream" gets updated but the formulas "upstream" don't get re-evaluated.
I read about the usage of dag in this problem. But my question is how are the actual cells referenced in the formula. As a user, I type =B12C34, then add two columns after A and 5 rows after row 5. The formula is now =D17E39. If I add 2 rows at row 20, the formula becomes =D17*E41.
The offset-based approach is what I considered to be the most optimal so I’m happy to see that mentioned. So a complete solution would be a dag of offsets? A native internal representation would store something like:
(col 4, row 17) operator (offset col +1, row +24).
