Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I was wrong about spreadsheets (2017)

reifyworks.com

Post reply on HN
Print view View original

81–90 of 378 posts

Re: I was wrong about spreadsheets (2017)

#81

Post by jhoechtl »

keyle wrote: post #74
halfeatenpie wrote: post #26

I work in critical infrastructure planning. My organization builds software in R, Python, and other programming languages customized for these major organizations. So many critical infrastructures, billions of dollars in planning, and just systems are built out of Excel. It's amazing. You'd assume something that services millions of people a day would have some more sophisticated and customized solution, but you're w…

But how do you handle sharing? The main issue with Excel, and its main downfall, is the sharing of data and versioning, with person X has an older version of person Y by a few hours and needs an email of person X to keep doing her job.

Sharepoint or Office 365

Re: I was wrong about spreadsheets (2017)

#82

Post by discordance »

keyle wrote: post #74
halfeatenpie wrote: post #26

I work in critical infrastructure planning. My organization builds software in R, Python, and other programming languages customized for these major organizations. So many critical infrastructures, billions of dollars in planning, and just systems are built out of Excel. It's amazing. You'd assume something that services millions of people a day would have some more sophisticated and customized solution, but you're w…

But how do you handle sharing? The main issue with Excel, and its main downfall, is the sharing of data and versioning, with person X has an older version of person Y by a few hours and needs an email of person X to keep doing her job.

If it's O365 Excel, then you can share and work on the same spreadsheet in a similar way to Google Sheets (seeing other peoples real time cursor in your spreadsheet etc).

Re: I was wrong about spreadsheets (2017)

#84

Post by dolmen »

The_suffocated wrote: post #75

One major drawback of using spreadsheets is that it is harder to spot calculation mistakes. A famous/infamous recent example is the Reinhart and Rogoff incident in 2013, which involved their heavily cited paper "Growth in a time of debt". When a research student named Thomas Herndon tried to replicate the paper's findings, he found, after a careful inspection of the Excel spreadsheet the two Harvard professors used,…

TL;DR: code review from a spreadsheet is a nightmare.

Re: I was wrong about spreadsheets (2017)

#85

Post by mikekchar »

My biggest problem with Excel as a "solution" is that document control is kind of an afterthought. You've got X number of people in your organisation and they each have these adhoc collections of Excel spreadsheets. Usually the devil is in the details and you'll have one person who has calculated gross revenue one way and another person who has done it another way. The two approaches are never reconciled, but their output will invariably be compared as if they are discussing apples and apples. I've seen so much analysis done that was really just garbage because nobody understands where the data came from and what it means.

It's not really fair to blame Excel -- it's a calculation tool. However your solution space needs to address this problem and I very, very rarely see it happen.

Re: I was wrong about spreadsheets (2017)

#86

Post by beefield »

TBurette wrote: post #35
viraptor wrote: post #21

My issue with spreadsheets is that they could be improved a lot with minimal changes, not nobody seems to do it in popular office packages. Making them more database-like and making table data first-class (at least you can make named tables in excel on windows) could be used to push people a bit more towards organised data, without changing how anything works. Half of the mess that makes excel hell comes from the fac…

That's what Excel Tables are for. You get a table within your spreadsheet and instead of using cell references like =Sum(C2:C7), you can use structured reference like =SUM(DeptSales[Sales Amount])

I have quite actively tried to avoid excel lately (which means also avoiding to learn new tricks...), and I am not that familiar with tables. Do the tables:

1. Enforce same data type per column. I.e., if you have a number in C4, you can't enter text into C5?

2. Enforce that if there is a formula, it is applied identically to each row?

(By enforcing I mean that there is _no_ way around that short of copying the data to new sheet)

Give me those two things (preferably within sheet context instead of table context) and a decent version control and I can reconsider that I do anything but disposable ad-hoc in excel again.

Re: I was wrong about spreadsheets (2017)

#87

Post by keyle »

jhoechtl wrote: post #81
keyle wrote: post #74

Earlier quoted context omitted.

But how do you handle sharing? The main issue with Excel, and its main downfall, is the sharing of data and versioning, with person X has an older version of person Y by a few hours and needs an email of person X to keep doing her job.

Sharepoint or Office 365

Thanks I actually didn't know that.

Re: I was wrong about spreadsheets (2017)

#88

Post by tsimionescu »

keyle wrote: post #74
halfeatenpie wrote: post #26

I work in critical infrastructure planning. My organization builds software in R, Python, and other programming languages customized for these major organizations. So many critical infrastructures, billions of dollars in planning, and just systems are built out of Excel. It's amazing. You'd assume something that services millions of people a day would have some more sophisticated and customized solution, but you're w…

But how do you handle sharing? The main issue with Excel, and its main downfall, is the sharing of data and versioning, with person X has an older version of person Y by a few hours and needs an email of person X to keep doing her job.

Sharing Excel sheets is extremely easy - you just mail them, or host them in some online place, like SharePoint if you've bought into the whole MS ecosystem like many companies do. Not sure what your point is there.

Versioning is of course more difficult, though Excel does support diffing in principle. I expect though that what most people end up doing is simply keeping track of versions manually, same as they would have in the days before excel.

Re: I was wrong about spreadsheets (2017)

#89

Post by kgwgk »

tonygrue wrote: post #43
viraptor wrote: post #21

My issue with spreadsheets is that they could be improved a lot with minimal changes, not nobody seems to do it in popular office packages. Making them more database-like and making table data first-class (at least you can make named tables in excel on windows) could be used to push people a bit more towards organised data, without changing how anything works. Half of the mess that makes excel hell comes from the fac…

I'd be over the moon to see one change to Excel. Native support for a language other than VBA. Perhaps the CLR. Perhaps Java/Typescript. Just something (optional) for programmers who want to use Excel and not want to deal with the garbage that VBA is. Some workarounds exist, but afaik they require collaborators to also have the tool install, which is dead in the water. I know MS has considered it, I'm still pretty su…

Microsoft would also like to see that change, that’s why they tried to kill VBA. The reason for not following through (in killing VBA, because they definitely support and prefer other extension mechanisms) was pushback from users.

Re: I was wrong about spreadsheets (2017)

#90

Post by function_seven »

beefield wrote: post #86
TBurette wrote: post #35

Earlier quoted context omitted.

That's what Excel Tables are for. You get a table within your spreadsheet and instead of using cell references like =Sum(C2:C7), you can use structured reference like =SUM(DeptSales[Sales Amount])

I have quite actively tried to avoid excel lately (which means also avoiding to learn new tricks...), and I am not that familiar with tables. Do the tables: 1. Enforce same data type per column. I.e., if you have a number in C4, you can't enter text into C5? 2. Enforce that if there is a formula, it is applied identically to each row? (By enforcing I mean that there is _no_ way around that short of copying the data t…

Unfortunately the answer is "no" to both #1 and #2.

It does do something close to those. Column data types are automatically carried over to the next row when inserting or appending rows to an existing table. But you're free to override it if you want for a particular cell

Same with formulas. When you enter a formula in one cell, Excel will automatically copy across the whole column. But you're able to undo that auto copy if you really just want the formula in that one cell. It'll also flag cells that have inconsistent (compared to rest of table) formulas.

So, no, it doesn't enforce. But it does encourage.

Post reply on HN