Live data from Hacker News

I was wrong about spreadsheets (2017)

reifyworks.com

251–260 of 378 posts

Re: I was wrong about spreadsheets (2017)

#251
post #207

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…

Yeah it works and you don't need support contracts and then: - Fidelity's "Minus Sign Mistake": loss of $1.3 billion - TransAlta "Clerical Error": loss of $24 million - Fannie Mae "Honest mistake": loss of $1.3 billion Then you get employee turn over where new employees don't get "arcane" knowledge passed down by people who left and took their spreadsheet foo with them. Excel does not have "access control", "auditing…

> - Fidelity's "Minus Sign Mistake": loss of $1.3 billion - TransAlta "Clerical Error": loss of $24 million - Fannie Mae "Honest mistake": loss of $1.3 billion

Weigh that against makes $X Billion due to correct usage of Excel multiplied thousands and thousands of times over. Survivorship bias at it's finest.

Excel isn't perfect and has notable downsides, but work gets done all of the time on them for the aforementioned reasons.

Re: I was wrong about spreadsheets (2017)

#252

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…

> I have deep respect for Excel. I do something around the same line as you describe (build better tools in R/Python for larger data problems) but I have a deep aversion to Excel. It's proprietary, has horrible standards (it does not support native UTF8 csv files for example), and is stuck in the 80's in terms of paradigm. And this is precisely the tool that prevents people from doing things more efficiently because…

Well if you're using Python, you're following an imperative/oop paradigm which goes back to the sixties, so I don't know why you'd criticize Excel for using a dataflow model. I can understand not wanting to use Excel because it's proprietary (but Libreoffice isn't) but I can can understand not wanting to deal with a lot of it's legacy cruft, but for the stuff that Excel does well, it does it a lot more quickly, more interactively, and more intuitively for most people than a similar solution in Python. In fact, one of the key benefits of an Excel solution is that you can see every step of your calculation which creates a degree of self documentation which you don't get with Python, for example.

Re: I was wrong about spreadsheets (2017)

#253

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…

> I have deep respect for Excel. I do something around the same line as you describe (build better tools in R/Python for larger data problems) but I have a deep aversion to Excel. It's proprietary, has horrible standards (it does not support native UTF8 csv files for example), and is stuck in the 80's in terms of paradigm. And this is precisely the tool that prevents people from doing things more efficiently because…

> it does not support native UTF8 csv files

It does though? You can export as a UTF-8 csv file...check the export options.

Re: I was wrong about spreadsheets (2017)

#255
post #117

That's all very well and good, but can I make a plea for organisations to stop using spreadsheets to produce tabled documents. This seems to be endemic for information security surveys and would be fine for questionnaires with preset answers, but when a question starts "Describe..." and wants a full description of your software development cycle from an InfoSec perspective, it's painful edit-wise - even if you can co…

As the guy on the other end who has to read the responses; it's not fun here either. Though, there's movement in the SaaS space that looks to solve a lot of this. Proper text input fields, automated yearly requests for update, audit logging and notifications (x party has responded, y party asks for clarification on question z, etc). Expensive though, but enterprise solutions always are...

Smartsheet is a really great example of this.

Re: I was wrong about spreadsheets (2017)

#256
I can't help but think that people using excel to accomplish their task instead of writing a program is a lot like Pythagoras doing geometry without algebra. When you get away from the numbers/code it makes it easier to visualize things.

Re: I was wrong about spreadsheets (2017)

#257

The European Spreadsheet Risk Interest Group estimates that >90% of Spreadsheets contain errors/bugs. http://www.eusprig.org/

What percentage of software would you say contains bugs?

Clean error bugs are much less dangerous than silent data corruption. Spreadsheets are like a memory-unsafe language in that respect.

Re: I was wrong about spreadsheets (2017)

#258
post #8

I feel the same way about Access, too. It doesn't matter whether they're "real programming", it matters that they let real people solve real world problems for themselves, who otherwise would have to pay real programmers real money to develop real applications.

Has Access solved the corruption issue that plagued it for tens of years? While you can connect it to a "real" database engine trivially, a common use-case is via a single MDB file that could become damaged. You could damage the MDB a number of ways including: - Leave Access running before shutdown (or power loss) - Intermittent network outage to the file server - Multiple users trying to access the same MDB (or anti…

I used to build Access applications and never had data corruption issues while supporting 20 concurrent users.

The key is separating the database and front end in different files.

While I have many gripes with Access, it is a highly underrated tool.

Using a real database engine requires infrastructure and lots of red tape to set up and it might not even be approved after waiting for months.

With Access, you just put a file in a shared directory and you are done. No need to set up a web server for a front end either.

Re: I was wrong about spreadsheets (2017)

#259
There's nothing WRONG with the spreadsheet model, and never has been. It's immensely powerful and useful, and the growth in capability over the life of a product like Excel is remarkable and enviable. Excel is perhaps Microsoft's greatest product.

The problem with it -- and there IS a problem -- is really a problem of applicability. Excel, like Lotus before it, is the first place many people encounter the ability to create their own logical conditions.

For a huge subset of these people, it's also the LAST such tool they learn. And now they have a hammer, so everything is a nail. I don't just mean finance people who live and die by spreadsheets; I've met engineers who would solve problems in Excel macros that would've been better attacked in perl or Python.

The other "problem" is the degree to which a horrifying number of organizations end up depending on very, very complex spreadsheets full of arcane and undocumented formulas and macros, and for which change control is "save-as."

But, again, none of this is a problem with the product itself, or with the idea of spreadsheets.

Re: I was wrong about spreadsheets (2017)

#260
post #207

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…

Yeah it works and you don't need support contracts and then: - Fidelity's "Minus Sign Mistake": loss of $1.3 billion - TransAlta "Clerical Error": loss of $24 million - Fannie Mae "Honest mistake": loss of $1.3 billion Then you get employee turn over where new employees don't get "arcane" knowledge passed down by people who left and took their spreadsheet foo with them. Excel does not have "access control", "auditing…

>Then you get employee turn over where new employees don't get "arcane" knowledge passed down by people who left and took their spreadsheet foo with them.

Yeah, this never happens with a proprietary codebase!

Post reply on HN