Stuff is organized in a manner someone unfamiliar with data handling or programming can understand it.
It takes a little bit to master, an some stuff (like looks and variable passing) is still unintuitive.
Most nodes (there are official and 3rd party nodes) do have error output, and there's a console to inspect what's going on.
You can also inspect data visually in most nodes.
Even someone who is not used to play with data, who doesn't understand consistency and yada yada will understand the advantages.
It uses a visual data flow approach to transform data step by step from one form to another. This approach is much better for data transformation. It is also less error prone as operations take place on columns or rows of data, not cells. But you wouldn't try to create a set of company accounts with it.
That's what's frustrating about these anti-Excel discussions.
Ok. What happens when I say that the company bought another company and it had a product line that the new company wanted to pay sales people commissions on? And the compensation plan around it was complex.
For whatever reasons, that's not a report the DBA was up for developing from scratch (or, someone decided his time wasn't to be used that way). That's just the reality.
We can talk about what should have been or what ought to have been, but that doesn't change the reality.
The reality is that I ended up doing most of it ACCURATELY in Excel.
Yes, like a janitor for example.
> The reality is that I ended up doing most of it ACCURATELY in Excel.
Yes it's the hammer for all your nails. You could also use Python+Jupyter. There are selfhosted and managed versions.
Because of guys like you, municipial installations run their sewage system with an excel sheet because some guy implemented a vba macro to talk to the sewage api endpoint.
let it go.
Or maybe not, and they’d just hire more people solely to calculate commission :/
- The process involved 2 people checking my work before it was sent to payroll. And we did catch and correct mistakes. We were able to trace back where and how the mistakes were make, and build in ways to prevent or flag future mistakes.
- The job was necessary because of all the garbage in the database. Excel's data-checking and data-cleansing and flexibility was superior to the database.
- After 1 year all of my work was audited. For several dozen sales people, there was ONE person I wasn't 100% accurate with. And that one was off by 0.5%. SUCCESS!
- If we'd gone with the report coming out of the database, things would have been such a confused mess.
But ok. So what you are saying your Excel was reviewed by somebody else. How is this any different from reviewing somebody else’s code?
I work in a company where even the least technical analysts are capable of using numpy. We have libraries to use Google Sheets as input-output data. So you get the best of the two worlds.
What does Excel resolve here?
And I also do not believe that a python script would not do the same cleansing of the data in a much more maintainable way.
Why didn't you jump in and help us?
Also I am going to underline that what you did was relevant 16 years ago; which you did not state in your initial message about the usefullness of Excel.
Which is kinda funny, if I didn’t ask you would have otherwise omitted a lot of otherwise relevant information which makes your opinion even less important.
It only makes me question why do you take this whole thread so personally? Probably because by now your skills are way less relevant than back in 2005.
What is the first tool a BA would reach for for most of these problems?
This is so frustrating because I've worked in small departments in an international company. Our problems were too small to get consistent, needed help from IT and we weren't important enough to get one of the limited licenses to the fancy reporting system.
Ultimately, there's all this bad talk about evil Excel, but we get no help or other resources.
And what about all the junk reports that were coming out of the company database that no one wanted to spend the money to fix?
THE ONLY VIABLE ALTERNATIVE WAS EXCEL.
I'm just offering the context from which weird stuff happens. And the answer isn't always as easy as: put it in a database.
The context, the processes (or lack of processes), the decision-makers, budgets, timelines, they all play a part in the outcomes.
One thing Excel is extremely bad at is reliably importing data from CSV. It's unbelievable what errors you can get if you're not extremely careful.
They can do it by themselves with Excel. Can they do that with any other software?
Not many people would be able to do complex calculations in an RDBMS, especially if it requires joins or grouping. But many more are able to use a GUI tool to create a single database table and import some CSV data.
The recent UK disaster wouldn't have happened if the data had been imported into Access or SQLite instead of an Excel sheet.
Of course it's not a panacea. Badly designed databases can be just as error prone as Excel, but they have different error modes.
But when developers complain they have to learn domain specific items, people say the shall keep up with the times. but suddenly the analysts and the others are exempt from this?
Even if/when the "average Excel user" finally sees the Light ... s/he still has to work in an environment where excel files (including .csv) are the lingua franca.
It's a bit like working for the German (or French or Japanese etc.) branch of a US large company. Of course the official language is English, and all documents should be written in English and emails should be in English and so on. Even if everybody (down to the Janitor?) speak acceptable English and are perfectly able to talk business in English... everyone will still use German unless they have to communicate with someone like me, whose German fluency is rated in Imaginary Numbers.
Get into the world of the Excel user. Some of us do learn coding. But generally speaking? No. If it happens, it's on our own.
And we can agree that spreadsheets have problems, and Excel users typically are not data people.
BUT!
When we agree on that, it becomes evident that a lot of suggested solutions are non-starters. Not all Excel users are in an enterprise that's throwing money around for training and dedicated software.
I'd like to see the Warehouse Manager who goes in Monday morning and says to the company vice-president, "I've been looking into this Python class ... "
The Warehouse Manager or Sales Assistant doesn't need to learn an alternative, but e.g. the Finance people should. PowerBI/Tableau for reporting and R/Python for modelling should be a thing in those worlds (even if Excel continues to be an amazing tool for entry level stuff and some quick number crunching).
In my experience these take ages to load data that is near instant on Excel. I can totally see how people prefer excel.
Do I need to say it again? My Excel skills were necessary because of garbage in databases.
I could sit at my desk; extract a data-dump of 50k rows of data; locate the fuzzy matches, identify which records needed to be kept and which ones deleted; merge it with the client's spreadsheet that they emailed to me and compare them; identify problems and report back to the angry client.
Why was the client angry? Because of inflexible garbage reports coming out of the database that people were blindly trusting.
Why was there garbage in the database? Not because of Excel.
Can’t we simply accept this for what it is? Code nerds preferring a code solution while normal people simply use the modern equivalent of graph paper?
This Libre Office question&answer[1] in 2020 says it guesses that the users want leading zeros removed from numbers. This behavior is similar to other software tools I looked at.[2]
This means that if a csv has "02142021" as a date for Valentine's Day with a leading zero, it will be imported as number "2142021" -- unless one takes extra steps to prevent the default behavior.
[1] https://ask.libreoffice.org/en/question/246295/how-can-i-imp...
There is ages since I opened an excel and I don't miss it.
- Alteryx at $5000/year/user?
- A database that requires specialized skill or going through a DBA for every little need?
- Salesforce? It's hell to configure if you don't have the skill.
- Sharepoint? Again. If you're a small business or nonprofit, you've gotta hire or train someone before this is a serious conversation.
I would in no way suggest that an enterprise can run on Excel with centralized data and multiple users. And that's where I believe a lot of criticism of Excel is unfair: the comparisons are not apples to apples.
And let's be honest. EVERYTHING comes with a level of human error.
- Enterprise level databases can get so big that the corrupt data in them can be impossible to cleanse.
- Reports made by SQL people are often flawed.
Over my 7 years in an international company I discovered report after report that didn't accurately match business rules or they were based on loads of incomplete records, duplicates, inconsistencies, incorrect math, etc.
How about fixing the reports? Often the decision was "no." Fixing the reports wasn't something a department head wanted to pay a consultant for.
Eventually, I had the DBA stop sending me reports. I started exporting the raw data into Excel and made my own reports.
- Brand new reports can be impossible to get if they don't justify the cost of a consultant to create the report. (Ah, but there's Excel.)
- Databases get hacked and they crash.
So. Where's the tool that's perfect, free and easy to use? It doesn't exist.