Live data from Hacker News

You shouldn’t use a spreadsheet for important work

lemire.me

51–60 of 200 posts

Re: You shouldn’t use a spreadsheet for important work

#51
post #11

Honestly, I don't have a problem with the fact that Excel is used in so many cases - programming for non-programmers is important. My problem is that Excel is terrible . Its formula system is painful and the formulas are invisible. It's not that a light user DB/spreadsheet program is a bad idea, it's that Excel made a lot of terrible decisions 20 years ago and now they're married to them.

>"My problem is that Excel is terrible" Do you know a better alternative? I have used LibreOffice and Numbers and I will take Excel any day. Saying that it is terrible is a very strong statement for a piece of software that arguably is what keep a lot of people in the Windows world.

Every 3rd-party approach is trying to replicate Excel's featureset and maintain compatibility of excel. That means any of Excel's idiosyncracies must be copied as well.

A re-think of the spreadsheet to be a little closer to a SQL database (but still layman-friendly) would be far more sensible. I wish something like Lotus Improv had won.

Re: You shouldn’t use a spreadsheet for important work

#54

Earlier quoted context omitted.

I remember on job where I wrote a lot of tools to load a database by reading an excel spreadsheet from perl[1]. It was amazingly fun. 1) perl does have some good libraries to read Excel files without exporting

Perl also has nice libraries for creating Excel files. Used that at my last job to generate reports from MySQL.

Yep, it is amazing how much b_tching about crappy reports ends when you just give the raw data to a customer and let them pivot table to their heart's desire.

Re: You shouldn’t use a spreadsheet for important work

#55

Wrong end of the correlation/causation pattern. Human beings make mistakes. A lot of humans use Excel. Hence a lot of errors in Excel. Would all those humans program their logic in Python - we'd have a lot of wrong calculations in Python code and an article stating to not use Python.

At least Python will ease the testing of the various functions you code. Everything won't be hidden inside cell all over the pages

Re: You shouldn’t use a spreadsheet for important work

#56

In my experience most civil engineering organisations use spreadsheets for the majority of design calculations. Some large organisations even still insist on engineers writing out calcs by hand. For example, a calculation that determines whether or not a retaining wall is of sufficient size more often than not will be completed in excel. Ditto with the calculation that checks the weight bearing capability of a column…

This is what I'm hoping to do with a software background going to more traditional engineering.

It's just a little offputting when people talk about the tools they (have) to use -- When I first started, I would never have expected Excel to be so prominent, and Matlab so absent.

Re: You shouldn’t use a spreadsheet for important work

#57

I'll buy that - the fact that the pretty essential vlookup function defaults to guessing when it can't find a value, rather than defaulting to "Couldn't find the value you were looking to" - has been the source of endless errors. Explicit really reduces the number of errors you run into - there's a lot of implicit going on in a spreadsheet.

I think you'll find that VLOOKUP is not used that much by people deeply invested in the modelling field. It is dangerous in the same way as referring to cell addresses in macros. (This is where named ranges are particularly useful)

As soon as the structure of your lookup table changes, your VLOOKUP formulas risk being invalidated. After being burned a bunch of times, I've switched to INDEX or a INDEX/MATCH to accomplish the same sort of thing. With INDEX/MATCH, you are required to be explicit in selecting both the range of the data and of the key.

Re: You shouldn’t use a spreadsheet for important work

#58

Wrong end of the correlation/causation pattern. Human beings make mistakes. A lot of humans use Excel. Hence a lot of errors in Excel. Would all those humans program their logic in Python - we'd have a lot of wrong calculations in Python code and an article stating to not use Python.

At least Python will ease the testing of the various functions you code. Everything won't be hidden inside cell all over the pages

Apparently the errors found were "transcription errors" not "programming errors." Using Excel or not then is irrelevant.

Excel (and any other spreadsheet) is a nice and convenient tool to get easy tabular inputs and some results fast. Spreadsheets were one of the first useful programs on PCs.

Re: You shouldn’t use a spreadsheet for important work

#59
post #51

Earlier quoted context omitted.

>"My problem is that Excel is terrible" Do you know a better alternative? I have used LibreOffice and Numbers and I will take Excel any day. Saying that it is terrible is a very strong statement for a piece of software that arguably is what keep a lot of people in the Windows world.

Every 3rd-party approach is trying to replicate Excel's featureset and maintain compatibility of excel. That means any of Excel's idiosyncracies must be copied as well. A re-think of the spreadsheet to be a little closer to a SQL database (but still layman-friendly) would be far more sensible. I wish something like Lotus Improv had won.

For all practical purposes, it's called MS Access. :)

Re: You shouldn’t use a spreadsheet for important work

#60

Felienne Hermans has done some very interesting work examining how to refactor spreadsheets. ( http://www.felienne.com/publications ) Her PhD dissertation on the subject "Analyzing and Visualizing Spreadsheets" ( http://www.felienne.com/archives/2534 ) is particularly detailed. Much though some people might think that spreadsheets are not for serious work, they're being used for that right now, and that is unlikely t…

> Much though some people might think that spreadsheets are not for serious work, they're being used for that right now, and that is unlikely to change. Better to figure out how to improve the tooling, rather than undertake the quixotic quest to get business people to abandon their perfectly viable programming tool.

Its largely used by business people because they (1) have inadequate IT support to have things developed using proper tooling, and (2) have been forbidden from using better tooling themselves by IT. Since both of these are direct products of IT policy, I don't think its a quixotic quest to fix it -- however, trying to fix it by trying to convince them to just give it up is the wrong approach. The people who need to be convinced to change the situation are CIOs.

Post reply on HN