Spreadsheets really are the fullest realization we've seen of functional-programming-without-code, and with a built-in (rudimentary) database too. It's no wonder they kicked off the microcomputer era and remain essential to this day.
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.
A lot of companies don’t want to invest in tech they don’t control or understand.
no. this does not happen. everyone uses excel.
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.
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.
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.
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.
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.
Without difficulty? No, definitely not. The difficulty is always there, it's just internalized, ignored or worked around in various (often crazy) ways.
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.
I've seen these trends around "Unbundling" Excel:
- Improve UX by specializing UI
- Increase automation with software integration
1) Running business of Excel has many of the same problems as other software
2) Excel has some key advantages over other software
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.
Does the experience of Sharepoint bear this out?
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).
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.
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.
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”.
About two weeks later, I showed her how to use Excel, and she took to that immediately, and uses it for nearly everything. It's to a point now to where I wonder if she'd pick up Go better as a result of her experience with spreadsheets.
They absolutely are databases. What definition of database are you referring to? Google's dictionary defines it as
"a structured set of data held in a computer, especially one that is accessible in various ways."
That's a spreadsheet.
This advantage shows when using Excel positionally rather than as a simple data table system. For example, =B7*C6 is virtually impossible to express in SQL, and constructing positional lookups using concepts such as “the previous row” or “the next column” are virtually impossible - yet, easy in Excel:
INDIRECT(ADDRESS(1+ROW(H229),COLUMN(H229),3)
Excel’s ability to write non-tabular data and calculations alongside tabular data, without needing to split it onto another tab/pane/page, is another critical benefit that databases cannot match. While they have stored procedures and linked functions, they have no concept of “positional” with which to model the theory of canvas that underlies Excel.
Finally, due to being a canvas model with calculation functionality, Excel meets the basic needs of a page layout and data graphing engine, with the ability to configure and position reporting in various UX ways that are considered out of scope for nearly all databases. HyperCard, FrameMaker, MS Access all clearly understand this issue and work to solve it in various respects.
So while the written definition of spreadsheet may seem to be encompassed by the word “database”, that is true only if the word “database” encompasses canvases that store both tabular data and other content, and not just key-value data (such as a MongoDB or anything SQL).
If you want to break into the Excel market, you won’t do it with a database alone. You’ll need canvas UX to even begin to be relevant, a point many startups discover the hard way.
As I wrote initially, if you losen the definition that much, then a txt and literally everything is a database.
There are many different definitions but my personal completely subjective perspective is that the bare minimum is that whatever structure you claim the data has must be enforced and be translatable to a semantic connection. For most sql databases you have a schema enforcing the structure and at a minimum there is a connection between different pieces of data in the same row.
In a spreadsheet having different sets of numbers/text/code on the same row or column might mean something but doesn’t have to. So whatever “structure” there is, is not enforced.
This is in the same sense that a txt document that contains 4 book chapters have in them 3 email addresses is a “structured list of emails” sure you could find them and there is a structure to it, but calling it a database is a stretch in my book.
Are you arguing that flat file databases aren't databases? Because they really are.
There are plenty of computer programs that use text files as databases, reading and writing lines. /etc/passwd is one very common example, the passwd file is just a text database that you can read with any text editor.
I mean a HN comment is also a database, a text is a database, a picture of rocks arranger i the shape of names is a database.
In the world of stupid internet arguments, sure we can agree you are right txtfiles are database, .wav files are database, everything is a database. Talk this way about it at a job interview and you’ll get cut by your second sentence
>> Yes, but by that definition every group of bits on a computer is a database. The word sort of loses any value.
Not exactly. We need to define the atomicity we would like to deal with. That is:
- if a bit is what the atomic unit of data is, then a byte is a database
- if a byte is what the atomic unit of data is, then a collection of bytes in properly defined structure is a database. For example, a JPEG file or little-endian or big-endian datatypes.
>> I mean a HN comment is also a database, a text is a database, a picture of rocks arranger i the shape of names is a database.
If a word is the atomic unit, then a comment can be a database. If the comment itself is an atomic unit, then the thread can be a database.