Live data from Hacker News

You shouldn’t use a spreadsheet for important work

lemire.me

121–130 of 200 posts

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

#121
post #75

Earlier quoted context omitted.

A lot of people who have access to Excel also have access to Access - and a lot of what they do would be better served in database than a spreadsheet. Yet they don't use one - there must be a reason for that, and I don't think it's IT restrictions.

This little tidbit from Chris Granger seems relevant: "Excel is inherently observable since it doesn't have any hidden state and all values are there for you to see and manipulate. It's also direct. You change values in the grid, drag drop things, do calculations on selections, and so on. And it manages to sidestep a lot of incidental complexity; spreadsheets are timeless, without setup, and don't even have a notion…

> Excel is inherently observable since it doesn't have any hidden state

Except that it does -- even in terms of simple numerical values what you see is not necessarily the actual value, but instead the result of passing the value through a format string that can vary by cell.

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

#122
The problem with spreadsheets to counter was Chris Granger is saying, is that they are NOT observable from a software maintenance perspective, the code is invisible but the entire heap and the intermediate values are visible.

I cannot easily swap out one set of data for another, making it hard to confirm my models are running correctly.

How do I diff a spreadsheet?

How do I refactor a spreadsheet?

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

#123
post #112
post #75

Earlier quoted context omitted.

A lot of people who have access to Excel also have access to Access - and a lot of what they do would be better served in database than a spreadsheet. Yet they don't use one - there must be a reason for that, and I don't think it's IT restrictions.

SQL is scary. I've talked to hundreds of customer prospects for Treasure Data, and by far the biggest surprise I encountered is how few people know their way around SQL. I am not talking about just "business" people but also programmers. Contrast this dearth of SQL-proficient population with the massive, massive Excel user base: I jokingly tell my friends that Excel is by far the most popular programming language =p

Access actually has (or had, it's been a long time) a very well put together visual query designer. As long as you weren't doing anything crazy you'd never need to touch SQL.

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

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

> A re-think of the spreadsheet to be a little closer to a SQL database (but still layman-friendly) would be far more sensible.

You could probably get there by cutting features out of Excel -- Excel has a lot of database-like features that can mitigate some of the problems of using it, the problem is that most of the people using it to what is easiest and most discoverable for the UI -- or what they learned as a power user 20 years ago, or learned cargo-cult fashion from (perhaps through intermediaries) someone who learned then -- so a lot of the features that are more clear and maintainable are rarely used.

i.e., the next time I encounter a spreadsheet in my work that I didn't design that uses column names in named tables for references rather than row/column references will be the first.

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

#125
Biggest issue I've had with excel and spreadsheets in general has been "put this on the web". People spend hours/days/weeks building a spreadsheet tool that does all their calculations, then say "put this on the web" to me, and I can't do it. Not in their budget. To them, it should just be some sort of magic, but... I don't know of tools to just 'put' something like that on the web. They want people to be able to interact with it, but 'not download it'. They won't use Google spreadsheets or any office365 online stuff.

Maybe there are some tools that can take an xlsx file and make it secure, interactive and loggable and are also free (or nearly so?) Am I missing something?

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

#126

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…

I developed a set of utilities for Excel (http://www.breezetree.com/spreadspeed/), and I started adding some auditing features to it. After spending a few weeks on the auditing tools, I decided that I should do a little market research before investing more time on auditing features. Well, I'm glad I did because I found out that the market is saturated with spreadsheet auditing tools. Most are simple and inexpensive (like mine), but there are some fairly sophisticated tools out there. So my takeaway from this is not that there aren't sufficient auditing tools, but that the market needs a non-programmer, user-friendly way to build robust yet malleable models.

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

#127
post #111
post #63

Earlier quoted context omitted.

Coincidentally, so did I. I agree with you 100%. iBankers use Excel because it does what they want. One of the main reasons I left was because I got tired of trying to re-invent the excel wheel with every piece of software. There was always an inherent lack of trust that any UI was "doing it properly," so we always had to add the failsafe of export to CSV so people could do it themselves in Excel. Mind-boggling ineff…

The value of export is beyond just checking on UI. If they can expert it to Excel, then they can do whatever simple data analysis they just made up. No reason to wait for IT to implement whatever stats they are curious about, order it in some new way or whatever. Doing those things in excel is very fast and they get to have complete control over it. Even if they only color cells and rows depending on some ad-hoc rule…

I don't disagree. The problem is that people are error prone, and excel doesn't value check. We had to build large BPM-driven processes in order to account for this. Also I don't want to imply that users got to test the system while it was being built. That would imply that there was a logical product development process in place, which for most projects, there wasn't. Users got something that had been frankensteined over the course of the project, and muckity-mucks wondered why projects and applications went stagnant because users stopped using them and went back to excel.

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

#128
post #112

Earlier quoted context omitted.

SQL is scary. I've talked to hundreds of customer prospects for Treasure Data, and by far the biggest surprise I encountered is how few people know their way around SQL. I am not talking about just "business" people but also programmers. Contrast this dearth of SQL-proficient population with the massive, massive Excel user base: I jokingly tell my friends that Excel is by far the most popular programming language =p

Much of the ORM market and NoSQL were precisely because programmers don't understand SQL.

That, and typing "select x from table A, table B where tableA.foreign_key = tableB.index and tableA.index=5" is a little long-winded and more prone to error, when you can just do x = ModelA.objects.get(pk=5).ModelB

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

#129
While spreadsheets are sub-optimal, the work was OPEN so people could find those bugs. We need to stop beating scientists who share their data because currently there is little incentive for them to do so.

Most scientists do not make their code and resources easily available. I'd prefer an open excel sheet to a closed python analysis which is only slightly less likely to be wrong.

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

#130

Spreadsheets ARE software, anyone arguing differently has insufficient experience in at least one of the fields to have an informed opinion. I've worked professionally in both, and the argument in this article is bunk. Spreadsheets are a different kind of software with advantages and disadvantages compared to compiled/scripted languages. How do you treat a spreadsheet as real software: * One operation per cell * Inpu…

… but I will not use Microsoft Excel to run a bank or to compute the trajectory of the space shuttle Does the author realize that Excel is not used to run banks or to track the space shuttle? Sure, some traders might base their models on Excel. But, the actual exchanges, trade routing and account general ledgers are all on very tightly controlled systems, usually mainframes in the case of ledgers. To boot, NASA does…

Does the author realize that Excel is not used to run banks or to track the space shuttle?

I'm sure he does. He's exaggerating for effect. (Well, at least he is regarding the Space Shuttle.)

Post reply on HN