Following spreadsheets is like trying to find something in my garage if all of the boxes have lids. But if the boxes are all open, I can find stuff in a jiffy, even if the boxes are disorganized.

It would take a 1 year project and 5 devs to replace what one finance person created in a day.

Then when it didnt work complain the SME got the requirements wrong.

Im being silly but as a dev i hate the hate for excel, though i know from years of experience that its also a nightmare.

Spreadsheets are code. Their user-facing side is a particular form of livecode oriented around "sheets"/2D arrays of data tightly connected with reactive code -- which definitely has some legibility advantages -- but they're code.

Auditability is legibility. The advantages help. But also the reasons why Excel code is legible to auditors probably have some things in common with the reasons Ruby code is legible to devs who've worked with Ruby or sufficiently-Ruby like languages: exposure, training, and culture that have coalesced around it.

And I'd guess that people who don't understand that spreadsheets are code are less likely to be able to read the limits of legibility past where there be dragons, fog, and possibly even fraud.

Um, what then is the point of an auditor?

The studies show the percentage of spreadsheets with errors in. Unless you have a reason to suspect this is not independent of the number of spreadsheets, I'm not sure what your point is?

> Now think of 100 pieces of software that you are confident are 100% error free?

Because software is either buggy or not buggy? And measurements like "defect rate" (e.g. defects/kloc) and "bug severity" do not exist? Come on.

Edit: My contention is that spreadsheets are in fact, very opaque, and it is incredibly difficult to check that every part of a spreadsheet is actually doing what its users think it is supposed to be doing. Specifically, I posit that it is harder to check a spreadsheet, than it is to check a "traditional" program in a normal programming language, which works on pure data.

Pdf is much less useful.

Excel on Mac is another ball of wax though. Bit of a dog, that.

Our finance teams use excel too, but not as the 'do everything' tool that the article and plenty of comments here makes it out to be. They use it as a scratchpad, and it works well. But it doesn't contain ground truth, ever.

This one perhaps matches with 99% of the rant I wrote:

> Then inventory, maybe the ERP didn't split it in the way your consolidation needs it, so you transform the data in Excel and reconcile it back

While we primarily deal with Dynamics (AX and 365), pretty much everything fits in there. In some cases the clunky UI makes it slow to do some transformations, even if just to check something to (as you wrote, verify the software did what it was supposed to do), and then you dump a couple of thousand rows out, do your work, and either are happy with what was verified or load some transformed data back in (this hasn't really been needed as we revised our rules as to data locations a few years ago, not in terms of "do this or you get fired" but in terms of "please make sure that when external systems outside of your team streams data in or out of the ERP, the chance of it not being correct is as low as you can get it").

As I wrote in some other reply (which some people appear to disagree with as if it's something I made up), my issue is with the horror cases of people building their own mini-ERP in a set of excel workbooks, or not using shared systems for data sharing and governance but instead emailing files around. Maybe it's the little learning being a dangerous thing, or feeling confident in a tool also giving people false confidence to perform actions that really should not be done that way.

30% of my jobs when I was in integration was unfucking folders of folders of irregular xls built by users, and sometimes we just failed due to the sheer amount of crap which was in motion and had to be transitioned atomically. It never worked first and second time, so we had to do waves of complex transitions with parallel accounting (double workload on an already suffocating business), until things failed rarely enough to be scheduled as regular bug fixing tasks.

We have software that does what is needed. An ERP, a CRM, a HMI, a case management system for legal etc. No need to have everyone on every team rebuild that in excel.

I my uninformed opinion it is because SOP (spreadsheet oriented programming) is as different from other paradigms as Forth is from Java. Decades of tribal fights have sort of culminated in a vague "all Software Engineering is Software Engineering" where most people understand that there are benefits even in the paradigms/languages they do not like.

In another world Excel would be just another one of those paradigms/languages but in this world it did not partecipate in the "Sotware Civil Wars" and so it was left out of the respectability plateau.

In short it is not that excel is bad but rather that the cultural link between it and what we usually call programming is very weak

No it isn't. This is MY take and I'm not an elitist software engineer.

> People building on Excel isn't a result of failure to educate, it's humans doing what humans do best—automating their own workload.

No, it isn't. It is human behaviour alright, but it's cutting corners because it feels better to do what you already know instead of doing what was instructed. This is what we see in businesses from 100 to 1000 people happening time after time.

Example: if you need to visualise your data from multiple sources company-wide, we'd have Tableau (and training, access, templates, portals etc) for example. That means you do it there as per instruction, and you don't go trying to setup some home-brew graph in excel that you manually regenerate every day and forget to generate when you are on vacation.

> It's people using general-purpose computers as general-purpose computers. It's the closest to the personal computing dream that we've come, and likely the closest we ever will.

Sure, do whatever you want at home, no discussion there. But since I already specifically wrote that, I suppose we don't need to keep repeating that.

> The alternative in the real world isn't "everyone learns Python", it's "we lock normal business people out of computing and keep it in the hands of the trained and very expensive software engineers".

No, it's not. The alternative is follow the workflows your teams and BUs have established and don't go off on your own. It works, it's proven, it's highly effective and attracts talent as a bonus.

> That's not going to happen, and it's frankly not something we should want to happen.

Maybe not where you are, but it's definitely happening here. And we want it to happen because the amount of data and the types of data don't work with excel. And the way people have tried to work around it by doing sampling and then saying "but it works on my machine" when it inevitably fails is a waste of time.

> I think this kind of Excel denigration comes up so often in software forums because we're usually called in to rescue a business when their Excel workflow gets completely unmanageable.

Perhaps, but what I wrote isn't Excel denigration, or denigration in general, it's real world scenarios where Excel wasn't the solution and people found out too late because they didn't know any better and they thought they were doing the right thing. Heck, replace excel with spreadsheet or 'workstation-based' and you have the same issue.

> We miss the decades that the company ran very successfully without any software engineers on the payroll and see the giant spaghetti mess that made them finally decide it was worth the cost.

You must have forgotten mainframes along the way, that's where the actual money was made, not spreadsheets. And if you create a 'spaghetti mess', that is something you can do perfectly fine with Excel, Access or just plain pen and paper. Creating a mess is at the core of end-user deficiencies when it comes to using a spreadsheet for non-spreadsheet problems.

> But it's important to remember that these same businesses reached the point where they could afford to pay us to build something custom by building a successful business on top of Excel.

No, it's not. It's important to remember that older software was written to emulate the physical world, but that was also what created boundaries and limitations. Desktops, folders, spreadsheets, word processors, rolodexes, telephones, paper mail etc. are not the 'best' solution, it just happened to be what was used when software was written. The software emulated the processes that existed to make it easier to understand what it means and how to use it for the people of that era. Practically everything has evolved beyond that, to the point where you have to educate new hires on what a file and folder structure is about if you're using those at work. Just like you have to educate older people that the way they used to do things is no longer how we do it today.

In some ways, Excel is the COBOL of our generation. And that is not a good thing.

I used to export to csv and use perl whenever I had to manipulate data. These days I even import to an sqlite database and use either the sqlite cli (or ruby).

Thanksfully I don't have to deal with excel files all too often.

When your sole goal is short-term thinking, and I don't believe this is Microsoft's goal but this is the user's goal that they're catering to, you get tools like Excel. It feels like a cost reduction because you're not having to retrain people you're not having to hire people who are interested in learning and interested in finding out new things. Microsoft is happy to do it because when you hit the functional limits of that tool or you have devised something so idiotically complex in that tool that no one else can understand it and you've forgotten yourself how to understand it there's a whole suite of consultants ready to take your money. So your short-term cost optimization has resulted in a long-term expense.

Your argument is that Excel is fine at being the one hammer that can do absolutely everything as good as purpose-built software is. That is factually wrong. I know it tries to be and it's okay at being average at many of these tasks and if average is good enough for you then go ahead and do it.

I for one choose to frame my house by using either a framing hammer or a power nailer that's made to drive framing nails. When I do my finish work I don't want mark up on my trim with big old Hammer marks from a framing hammer, so I choose to use a hammer that's made for finish nails or a brad nail gun or another tool that's made to do it so it looks professional.

You are welcome to live in a house that is built like trash and is marred up with "apprentice marks" as they're called. I will choose to be the master Craftsman.

I’ve seen all sorts of gross workarounds. The URL bar is my go to these days, mainly because that works on mobile.

I am not a fan of encoding information in the presentation layer and I would use an extra column to show the "certainty" explicitly, but using different fonts in addition is an excellent idea. Many thanks for this!

Even in this case, though, I doubt you would go over the threshold of 8 fonts that was mentioned.

Excel (and standard Windows and Office – the two are still slightly different, I think – selector controls call typefaces “Fonts” in the selector control. That doesn’t mean it is using “Fonts” the same way in the error message, but…)

https://support.microsoft.com/en-us/office/define-and-solve-...

> For example, you can change the amount of your projected advertising budget and see the effect on your projected profit amount.

I can do this without Solver.

https://workspaceupdates.googleblog.com/2024/05/tables-in-go...

Now add an extra column to pay extra (against the principal).

Now calculate total interest paid. Save this separately.

Now the fun part. Go back to the original and adjust the interest rate until the total interest paid is the same as the adjusted version.

You just found a way to reduce your interest “rate”.

I’m sorry but this sentence makes absolutely zero sense to my europoor brain.

What do you mean when you say mail a payment and why would you need to do that. I literally lack the imagination.

Nothing is.

I find explaining a few good computing practices coupled with a tour of the many fine OSS tools available literally for the asking, does real good for anyone willing to invest a bit of their time.

MS Office itself can corrupt its own documents. Ask many of us how we know, right? Now that is more rare than it is for the OSS tools, but it does happen.

You are not wrong. I am not sure what being right actually means in this context too. So yeah. I will just move on.

The most important aspects of all this boil down to people being able to do stuff other people would prefer they not do.

Further, should they be inclined to do said stuff, actually seeing it happen, and or, getting help to make it happen usually solidifies how important "Use Value" really is.

Unlike physical goods, software has the unique property of it increasing in value both as a sum of parts AND as more copies of it are made and used!

Think about that for a moment.

Done?

Great! Fact is that use value dynamic runs counter to our general and natural inclinations. I really enjoy it when people begin to think this way, embrace the tools, understand the culture and share it themselves.

From there, if they can learn to first build and then write software, they will have near fully bootstrapped themselves onto the best open computing and open data have to offer and we all see a fractional value change for the better.

Yeah, probably more of a response than expected. I sure did not start out with all this in mind myself!

It has been a while since I felt the need to express these things in the hope passers-by get something out of it they can use.

Their niche is clearly supposed to be in helping developers and data scientists make that same leap, from the tools and formats native to their data pipelines to feature-rich spreadsheets as an export/reporting/analysis format for consumption by people who otherwise don't code. CS V support (especially for huge files) is unusually important there.

Sadly, the world of native apps, at least in the commercial space, seems to be drifting away from the tenants of stability and user control that the space used to exemplify. Excel 365 (or whatever the hell MS wants to call it) randomly auto-updates itself without warning or confirmation.

They got some help by me for moving out the heavy stuff to SQL/BigQuery but that was also for the better. BigQuery and Sheets integrate very well these days so they could even use a Google sheet as a UI for the queries. Rows and columns, much better than any other web UI.

(Yes I believe you are being silly)

I created a simple function/macro once in Sheets to help me indicate when a group of rows were done; I had to watch my 3-5k sheet painfully iterate through every line and assign new colors. The script system even gave up at some point after I closed my laptop(? So much for online!..), and I had to manually restart it.

If a work place forced sheets on me, I’d resort to excel in the background. (I would fit in the excel power user category).

I recall how many hoops I had to get into to convert one data dump into anything readable on it. And the update latency goes up to several minutes for the same job that Excel would take barely a second to finish. No non-stupid employer will have their team use GSheets for anything serious no matter what "youngsters" may demand. Also, on a side note I haven't seen a single instance where any business decision was made keeping into account what young employees were originally familiar with.

You can test for yourself - try doing some complex operations on large datasets on both. See which one performs better.

[1]: https://support.apple.com/guide/numbers/autofill-cells-tan0e...