Hacker News new | past | comments | ask | show | jobs | submit login

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.



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.


I know more than one company with revenues >$1B where P&L roll-ups are still done manually in Excel.

A lot of companies don’t want to invest in tech they don’t control or understand.


My whole business used to be run on Zapier, Google Sheets, and Google Apps Script.


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.


“you’re going to leave excel in the dust pretty quick”

no. this does not happen. everyone uses excel.


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.


Accounts in Excel is a recipe for disaster


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.


Amen. 90% of the time, companies build process and automation on top of Excel. Success for SaaS is changing HOW companies use Excel, not IF.


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.

Does the experience of Sharepoint bear this out?


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...).


Right. It's Microsoft's for the taking, so long as they don't screw it up.


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.


One of the keynote speakers at Lambda Days in 2018 said something that I've agreed with for years: Excel is arguably the best programming language, largely because people are programming without even realizing that they are programming.


It’s because instead of seeing a set of instructions inside a loop, you see the instructions left to right and the loop iterations top to bottom. It’s fucking fantastic.


Yeah, no argument here. I tried getting my wife to learn how to program in Go, and while I think she's certainly smart enough to do it if she stuck with it, it wasn't really her thing.

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.


Spreadsheets aren’t without code, the code is just in cells. Spreadsheets are not functional. Spreadsheets are not a database for any sensible definition of database. If you losen the definition enough to include spreadsheets, then random scribbling of data into a .txt file is also a database “because the data is put into lines” like spreadsheets puts data/code/comments into cells.


> Spreadsheets are not a database for any sensible definition of database.

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.


Excel combines database principles of keyed list values with the non-database principle of locational calculation and canvas page layout.

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.


The structure in a spreadsheet is “all the stuff is in cells” and in a raw binary file it’s “ all the stuff is in a binary blob” in a txt file it’s “all the stuff is in lines in a file”.

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.


What about a document database without an enforced schema? For example, you can just install CouchDB, create a new database and start inserting random documents.


> in a txt file it’s “all the stuff is in lines in a file”.

Are you arguing that flat file databases aren't databases? Because they really are.


>random scribbling of data into a .txt file is also a database “because the data is put into lines”

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.


Yes, but by that definition every group of bits on a computer is a database. The word sort of loses any value.

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


I understand what you say. I mostly agree, but just wanted to push the semantics to the limit ;)

>> 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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: