The code in spreadsheets is always a 2nd-class or 3rd-class citizen. It makes it ridiculously hard to both test and review and there are essentially no good checks on what output you're getting from the input.
I've worked in orgs where C-level execs without a technical background were writing crazy complicated spreadsheets and nobody had any idea how they worked or if they were correct. When you bury the code, you bury the necessary processes around the code.
Why is everyone hating on Excel, and spreadsheets in general? They are such easy tools for creating, displaying and auditing calculations (like financial models), manipulating rows of similar data, and generating regular charts and reports.
Sure, their ease of use makes them popular with, and accessible to, people who don't think like we do. This doesn't mean they are bad tools for everyone. Python's duck typing may horrify Java programmers, but it doesn't mean that all Python code is bad or has type errors.
> Why is everyone hating on Excel, and spreadsheets in general?
Speaking for myself, because spreadsheets are intrinsically "information silos." Traditionally, this has been due to the data being locked up in the spreadsheet's proprietary files. This offering only exacerbates the issue by incorporating data from external sources which lack data management guarantees available in other solutions.
> They are such easy tools for creating, displaying and auditing calculations (like financial models), manipulating rows of similar data, and generating regular charts and reports.
When their use is restricted to this, spreadsheets do provide value. The problem is that many times the spreadsheets start off as a data integration scratch pad (as it were) and then become the "system of reference."
Used as a tool which enables one-off types of value it's hard to argue against them (so I won't :-)).
> Python's duck typing may horrify Java programmers, but it doesn't mean that all Python code is bad or has type errors.
This is a false dichotomy[1], or a straw man[2] if you prefer, as both Python and Java are general purpose programming languages.
Excel is not a general purpose programming language. It is not a programming language. It is a program which allows people to use a very specific DSL to benefit from it in novel ways. And when they do, any chance of autonomous integration is lost.
I've worked in orgs where C-level execs without a technical background were writing crazy complicated spreadsheets and nobody had any idea how they worked or if they were correct. When you bury the code, you bury the necessary processes around the code.
This is dangerous.