Live data from Hacker News

The Tyranny of Spreadsheets

timharford.com

51–60 of 282 posts

Re: The Tyranny of Spreadsheets

#51

Data caught in spreadsheets is kind of an instance of the general siloing of data. The situation is something of a general problem of a data-driven Society. One group of people want information available with one interface and spends resources only in putting it in a format suitable - to the detriment of others who/want need it. With spreadsheets in particular, naturally you have a data-integrity but that's still an…

So, what's your alternative?

Spreadsheets have many advantages, they are easy to edit, copy around, and quickly filter and do simple calculations (like find how many students are in a class if size smaller than 10, for example). I can't think of a sensible alternative given current tools -- we should make better tools of course.

Re: The Tyranny of Spreadsheets

#52
The article is a nice read, but very inaccurate.

Most companies do not keep their books in spreadsheets. Perhaps there are some poor souls who use Excel for bookkeeping, but this is generally impossible for any company that is audited (so basically everything bigger than some micro company). Auditors will demand to store all bookkeeping data in some ERP system - that generally allows double entry bookkeeping and many other things "from the box".

There are hundreds of better or worse bookkeeping/ERP solutions around word - some are expensive (and can cost millions to implement and still suck), some are cheap and some are even free (OpenERP) -> they are the tools used to input and store bookkeeping data, not Excel. Those solutions often come with own fair share of problems, especially in implementation. There are various business and programming horror stories.

So the article talks first about double-entry, which is most basic form of bookkeeping, then proceeds to call it accounting (which is like a "bigger" term - because it involves much more things, e.g. reporting, calculation of accruals, tax..).

Then somehow we move from double-entry (not done to Excel), to the UK mishap, where some low level public office clerk used Excel to combine tables that show number of coronavirus cases. What does it have to do with bookkeeping or accounting? I dont know. I guess for some, keeping something on a list = "bookkeeping". What is just plain wrong terminology. If some programmer makes some table in a relational datbase - you probably dont call him a bookkeeper, or accountant. But using the logic of this article - they should be, what is obviously wrong.

In the UK case, Excel was used as a database - and something went wrong when combing data from multiple sources, because the people responsible did not check at all what they were doing. There are multiple questions here: did they use the correct tool? Why didnt they check via some report if all data was uploaded? Why did they use XLS format, which is from 2003, so 18 years old? Also "not checking what are you doing" happens not only to public servants, for example in programming there is the very well known case of MongoDB, that used math.random to randomly log just 10% of issues.

The whole "16k missing cases issue" was reported multiple times by multiple sources and the narrative changed few times: IMHO the most plausible explanation is that UK government wanted to cook the books, so they made a bad way of consolidating data (that reduced number of cases) and when someone detected that it does not add up, they blamed it "on the computer". Public will eat it up, since everyone made some mistake. What is confusing for me that programmers also buy this. If your program does something wrong, probably there is the issue with the program. If some Excel VBA macro did something wrong when consolidating data - this is somehow problem with Excel, not the macro, or the ones who used it and didnt check it if even works.

In fact the first time they reported the problem, they said that they stored each data in a separate column. Excel 2007+ had a limit of 16384 columns, so one could argue that Excel is better than PostgreSQL, because PosgreSQL has a limit of only 16 000 columns ;)

So if some bad programmer also used a real database wrong, same issue could happen. And please dont act there arent many bad programmers in the wild - when a new guy comes usually you hear that the previous code is spaghetti garbage, what is often quite true. There are lots of programming horror stories. There are also lots of accounting horror stories. And lots of Excel horror stories. But the missing 16k cases has nothing related to double-entry, or accounting. You dont store cases on some income statement or balance sheet account...

If someone confused a motorcycle with a car, they would probably receive a lot of shit. Here we have same case: collecting few tables to make 1 big list has nothing to do with accounting. Or double entry. As I said, it is nice read, but completely wrong terminology.

Re: The Tyranny of Spreadsheets

#54
post #17

I hate Excel, not because it's a bad program but because in my experience people misuse it more often than not. Excel excels at creating spreadsheets. Spreadsheets are pretty reports used to report tabular data. Excel is capable of so much more, but for eveything beyond spreadsheets it's medicore at best and its complexity often makes it a liability. It's a bad calculator. It's a bad database. It's a bad medium for t…

I completely agree with your main point: excel is terrible because people use it for everything.

I've noticed there different ways people use excel: as a dashboard, to store data, to modify data.

IMO storing data is the worst use of excel, especially when it's done in a non 'tidy' fashion , with highlights and formatting to encode data.

This is from my experience as an R and python user in science.

Re: The Tyranny of Spreadsheets

#55
post #29

i think spreadsheets could represent an interesting future programming paradigm, but excel is not the tool that'll do it.

Notebooks are the next-gen spreadsheets, except they use programming languages instead of formulas.

And they require so much additional setup and processing power that they will never supplant spreadsheets.

Re: The Tyranny of Spreadsheets

#56
post #29

i think spreadsheets could represent an interesting future programming paradigm, but excel is not the tool that'll do it.

Notebooks are the next-gen spreadsheets, except they use programming languages instead of formulas.

Jupyter is a joke compared to spreadsheets, it doesn't auto-recalculate when you edit cells.

Re: The Tyranny of Spreadsheets

#57
post #44

Earlier quoted context omitted.

You would have the script take in the data as input from somewhere else, maybe your organizations shared drive. could be a .csv or whatever format. could be a database like sqlite. Much better than some big hulking macro heavy excel workbook.

Then how do I edit, extend and quickly filter and search that CSV? I'd probably do it with Excel to be honest. Lots of data in business isn't generated by another program, it's built and maintained by users.

Python or R have tons of ways to edit, extend, and quickly filter and search within stuff like a CSV. You could even do all of that with a bash script. It will probably run a whole lot faster on your computer than opening the excel workbook.

Re: The Tyranny of Spreadsheets

#59

In my last company we keep a spreadsheet that has tabs occupying almost the maximun number of columns allowed and in different headers. Updating that Excel file needs the full team to work for two full days each month. That was after I created a VBA script to scrape data from internal dashboards and put them directly in the spreadsheet. From my experience these monstrosities are usually created by two reasons: Push f…

Maximum number of columns is 16 384 (in modern Excel). PostreSQL has a limit of 16 000.

So Excel > PostrGRE? :)

I wonder what kind of data did you use and why it had to be stored in so many columns. This approach would probably kill a "real" database too.

Re: The Tyranny of Spreadsheets

#60
post #13
post #4

Spreadsheets are a hammer so if that's all you know then all problems look like the nail. Really, many power users of Excel ought to be looking at more capable, testable and readable solutions from professional data analysts and scientists. Python would be a good start, but there are many options better than Excel for critical systems.

what would python be working on then? a .csv, textfile, database, something else? Or would the data be stored as part of the script itself?

It varies and how you're outgrowing it. I heavily use spreadsheets, but if I start to hit some limits or need to formalize a process I'll switch to something like Python. As a data store I may still query the spreadsheet, or use csv, sqlite, or something that scrapes the data source. I really like columnar data because I like mucking with it by piping data on the command line (which has its own, well known ways to bungle data).

As for reasons you're outgrowing a spreadsheet; access and permissions, friendlier error messages or a better "wizard-like" process, formalizing input data, outgrowing data size, smarter caching for computing values, protection or clarity around modifying "constant" or "magic" numbers. Many of those you could implement in a spreadsheet, but its often more complex than using something else. That something else probably varies with which problem you're trying to solve.

Post reply on HN