'I grew up with it': readers on the enduring appeal of Microsoft Excel(theguardian.com)
theguardian.com
'I grew up with it': readers on the enduring appeal of Microsoft Excel
https://www.theguardian.com/technology/2024/oct/28/microsoft-excel-spreadsheet-program-40-years
375 comments
This is exactly right. I work in investment banking and the reason I believe Excel will never go away is because of how easy it is to follow extremely complex financing structures.
If I build a financial model, the 60 year old CFO needs to be able to understand it and agree with it.
One other aspect is all of the shortcuts and hot keys. If you switched to a different software you’d have to relearn shortcuts that you have been using for several years.
If I build a financial model, the 60 year old CFO needs to be able to understand it and agree with it.
One other aspect is all of the shortcuts and hot keys. If you switched to a different software you’d have to relearn shortcuts that you have been using for several years.
> 60 year old CFO
As a 59-year-old, I am extremely disappointed in your insinuation that people our age are unfamiliar with modern technology. We built the foundations for all the cool stuff you whippersnappers take for granted, including Excel.
As a 59-year-old, I am extremely disappointed in your insinuation that people our age are unfamiliar with modern technology. We built the foundations for all the cool stuff you whippersnappers take for granted, including Excel.
I read the parent comment as "If I go to a 60 year old and present them a non-excel build, they will ask me why didn't I just use excel?"
it's more that a 60 yo has likely being using excel for 40 years and (almost certainly rightly) not interested in something else to model a business.
As other commenters explained, Excel is universal. Excel is the global manifestation of God on Earth. Excel is the final avatar. If Pythagoras were alive now, he would get Excel in an instant.
I'm an engineer/scientist and I find it super hard to follow other people's excel files. All you see if some data/numbers instead of the actual code/calculations.
I wrote a VB macro that displays the formula for a cell, next to the cell. Granted you have to add a cell (typically a column) to make space for it. It returns either a formula, or "constant" if the cell doesn't contain a formula. I could make it more sophisticated, but just those two things are enough to make spreadsheets a lot easier for me to follow.
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.
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.
The closed toolbox is a nice analogy for opening a sheet full of numbers. A foreign Excel sheet can take a lot of clicking around to get an idea of how it works sometimes.
Control-backtick toggles formulas. No need for VB(A).
Ah, I didn't know that. So I tried it.
It does display formulas, but by hiding the values. What my macro does is allow the formula to be displayed permanently in its own column.
Granted I'm one user out of many, and have switched to programming for any kind of quantitative work. but I'm still quite supportive of Excel.
It does display formulas, but by hiding the values. What my macro does is allow the formula to be displayed permanently in its own column.
Granted I'm one user out of many, and have switched to programming for any kind of quantitative work. but I'm still quite supportive of Excel.
Do you realize it toggles data and formula display?
That ought to be fine for anyone with more short term memory than a gnat.
Excel sheets are built visually so there is absolutely no sane way to parse them. Just the same thing as trying to restructure a pdf at the end of the day.
Yeah this is what Microsoft is trying to do with copilot.
But they couldn't figure it out either so it's limited to data formatted as table.
But they couldn't figure it out either so it's limited to data formatted as table.
They’ve removed that limitation now, I think. That said, I still haven’t found any use-case for Copilot within an Excel workbook that works (probably because I’ve only ever asked it to do very difficult things since I don’t need it for easy stuff). So there’s that.
Worked for a company whose automated options trading system was an.... excel spreadsheet. Every now and then I would need to RDP to a machine to RDP into another machine to restart it. Pain. So much pain.
What year?
I think it's important to think of Excel as a tool for modelling reality and not a tool for changing it. IMO Excel should not be producing data feeds that other tools expect real time access to, nor should it make API calls that mutate state on other platforms.
Cheeky response..
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.
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.
I'm sure they were glad they had you to fix their problems!
At that point why not code something using the Interop APIs to programatically interface with the spreadsheet? It's a PITA to code but it works.
> One other aspect is all of the shortcuts and hot keys. If you switched to a different software you’d have to relearn shortcuts that you have been using for several years.
This! I love Cursor’s IDE but, boy, does it really sh*t me off everytime I update it and they remove the keybinding for CMD + SHFT + L.
Like, seriously, you couldn’t chose a different combination for your added feature’s shortcut!?
It’s not like the ‘find all instances of’ shortcut is some hidden, unused gem, which you have to tickle the Gruffalo in order to access! It’s one of the most important shortcuts!
This! I love Cursor’s IDE but, boy, does it really sh*t me off everytime I update it and they remove the keybinding for CMD + SHFT + L.
Like, seriously, you couldn’t chose a different combination for your added feature’s shortcut!?
It’s not like the ‘find all instances of’ shortcut is some hidden, unused gem, which you have to tickle the Gruffalo in order to access! It’s one of the most important shortcuts!
Well it might be replaced by another spreadsheet. Maybe one that does actual innovation. I don't think people in the 80s ever thought that Lotus 1-2-3 would go away.
> the reason I believe Excel will never go away is because of how easy it is to follow extremely complex financing structures.
Can you give an example? I am unaware of such power.
Can you give an example? I am unaware of such power.
Excel spreadsheets are auditable?
If that's the case, why do studies show that so many Excel spreadsheets have major errors in them?
https://theconversation.com/spreadsheet-errors-can-have-disa...
https://phys.org/news/2024-08-business-spreadsheets-critical...
https://duckduckgo.com/?q=study+excel+spreadsheets+contain+e...
If that's the case, why do studies show that so many Excel spreadsheets have major errors in them?
https://theconversation.com/spreadsheet-errors-can-have-disa...
https://phys.org/news/2024-08-business-spreadsheets-critical...
https://duckduckgo.com/?q=study+excel+spreadsheets+contain+e...
Yes. Auditable in this context means something that can be examined by a financial auditor. Auditors understand and can check through Excel but they don't understand code. It is not on the auditor to guarantee that what they are looking at has no errors. Their statements on their audit reports say as much.
In my old job, we had to switch away from our working but ancient Information System to SAP for similar reasons.
In my old job, we had to switch away from our working but ancient Information System to SAP for similar reasons.
While it's true that an auditor can look at an excel spreadsheet, my experience is that they'll never really understand what's happening for anything more than the most basic spreadsheets. It's far too easy to build a spreadsheet that's completely inscrutable, and you end up with an audit that's very shallow.
Then the auditor should ask you to prove it another way. You may think you hoodwinked them, but don't be so sure that they didn't build their own model to check your work... They do this all the time when people say 'I don't know how it works, the ERP calculates it.'
If it can be done, but not done right, that's not a big win (except in an arbitrary legal regulatory sense) than something that can be done. (And of course software "can be audited" too, by a different professional.)
> Auditors understand and can check through Excel but they don't understand code.
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.
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.
I don't think you get it. They can just click around and see all of the numbers and all of the formulas. You can write notes and directions into the spreadsheet to explain what it's doing. It's code and a UI.
Everybody knows it's code, I've written thousands of lines of code to back single spreadsheets. But the output is always a spreadsheet that people can flip through and check the calculations themselves if they like. It's code that outputs code. But is that a helpful observation?
Everybody knows it's code, I've written thousands of lines of code to back single spreadsheets. But the output is always a spreadsheet that people can flip through and check the calculations themselves if they like. It's code that outputs code. But is that a helpful observation?
> I don't think you get it. They can just click around and see all of the numbers and all of the formulas. It's code and a UI.
I'm glad you apparently agree with my statements like "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," though that agreement does make it a bit strange to lead with "I don't think you get it."
> Everybody knows it's code
When someone enters the statement "Auditors understand and can check through Excel but they don't understand code" into the discussion -- or in other words saying that an Excel spreadsheet is not code (along with asserting that's why auditors can understand it) -- apparently not everyone does know this and so it's reasonable to reassert that a spreadsheet is made of code.
> people can flip through and check the calculations themselves if they like.
If, as in any other interpreter, they understand the spreadsheet code that's being interpreted and take the time to follow what it's doing. And that's one reason why the observation that spreadsheets are code can be helpful. The distinctive visual presentation and model of spreadsheets is a legibility convenience for sure, but it can also lull people into believing they're working with something less complex than code. It helps people keep in mind that what the spreadsheet appears to be doing may different from what it's actually doing, either because the complexity has pushed it beyond casual legibility (a common problem in all kinds of code), or perhaps because someone intentionally is using the full power of an interpreted functional reactive programming language (to say nothing of VBA macros) to intentionally hide some aspect of the spreadsheet's operations. It helps people keep in mind that whatever margin of accessibility Excel's affordances provide, it still requires some of the same kind of work to audit it that other forms of code would.
I'm glad you apparently agree with my statements like "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," though that agreement does make it a bit strange to lead with "I don't think you get it."
> Everybody knows it's code
When someone enters the statement "Auditors understand and can check through Excel but they don't understand code" into the discussion -- or in other words saying that an Excel spreadsheet is not code (along with asserting that's why auditors can understand it) -- apparently not everyone does know this and so it's reasonable to reassert that a spreadsheet is made of code.
> people can flip through and check the calculations themselves if they like.
If, as in any other interpreter, they understand the spreadsheet code that's being interpreted and take the time to follow what it's doing. And that's one reason why the observation that spreadsheets are code can be helpful. The distinctive visual presentation and model of spreadsheets is a legibility convenience for sure, but it can also lull people into believing they're working with something less complex than code. It helps people keep in mind that what the spreadsheet appears to be doing may different from what it's actually doing, either because the complexity has pushed it beyond casual legibility (a common problem in all kinds of code), or perhaps because someone intentionally is using the full power of an interpreted functional reactive programming language (to say nothing of VBA macros) to intentionally hide some aspect of the spreadsheet's operations. It helps people keep in mind that whatever margin of accessibility Excel's affordances provide, it still requires some of the same kind of work to audit it that other forms of code would.
You are nitpicking. I was referring to "code" in the traditional sense of C, C++, Javascript, etc contained in what are otherwise plain text files. I thought that my reference was ok given the HN audience but apparently not.
Excel supporting VBA macros blurs the lines but given that auditors spend so much time in Excel, they get to know that too. Now that Excel, has official support for Python, I suppose they'll need to have to come up to speed on that as well.
Excel supporting VBA macros blurs the lines but given that auditors spend so much time in Excel, they get to know that too. Now that Excel, has official support for Python, I suppose they'll need to have to come up to speed on that as well.
> It is not on the auditor to guarantee that what they are looking at has no errors.
Um, what then is the point of an auditor?
Um, what then is the point of an auditor?
"guarantee" is the key word. If you get a security audit, the security auditor doesn't "guarantee" you code/application is secure.
Right. It is more like a comprehensive series of spot checks. And like a security auditor, they have free rein to dig in to a particular area if they find something that doesn't smell right. I was on the Engineering side in my old job so I didn't interact with them too much, but here is one example: our company would claim depreciation on some test equipment and once I had to track down one of those pieces of test equipment and show that we indeed had the unit we claimed to have, down to the serial number. They didn't check for every piece of equipment, just the one.
Auditability is being able to back up what you claim with a record of some kind (receipt, purchase order, etc). Our QA group referred to this type of thing as "objective evidence". If your QA process says that you "shall have a design review", you need to prove that that review was held. In our case, our process said that minutes for that review had to be recorded. Our QA auditors would ask to see those minutes. Thank you ISO9001.
Auditability is being able to back up what you claim with a record of some kind (receipt, purchase order, etc). Our QA group referred to this type of thing as "objective evidence". If your QA process says that you "shall have a design review", you need to prove that that review was held. In our case, our process said that minutes for that review had to be recorded. Our QA auditors would ask to see those minutes. Thank you ISO9001.
Spreadsheets let you click any field and understand where it came from. Excel can be thought of as an amazing post-execution debugger where you can get a previous output and value for almost any piece of memory ("cell"). I would love a debugger that could do this post-execution for some output.
Not quite the same thing but https://en.wikipedia.org/wiki/Time_travel_debugging comes close.
It's not even in the same ballpark. With excel, you are inspecting _the output_ for a specific run. There is no equivalent in modern programming.
In this case even getting 99.99% of the way there is still practically worthless, as someone will be interacting with Excel millions of times throughout a career.
Because there are so many spreadsheets? My team probably created 100 last week.
Now think of 100 pieces of software that you are confident are 100% error free?
Now think of 100 pieces of software that you are confident are 100% error free?
> Because there are so many spreadsheets?
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.
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.
Unless your software is formally verified how would you know?
I have to say my experience as a user has been that all software is buggy to some extent. Anyone who has worked in software for a reasonable amount of time will have found a bug in their own code that apparently worked fine, but actually was not quite right.
Would anybody on hn stand up and say that they never had a bug?
I have to say my experience as a user has been that all software is buggy to some extent. Anyone who has worked in software for a reasonable amount of time will have found a bug in their own code that apparently worked fine, but actually was not quite right.
Would anybody on hn stand up and say that they never had a bug?
I think you misunderstand the point of the poster you are responding to.
They are trying to say that 100% error free is neither appropriate nor useful. It is a binary classification that throws away the important nuance.
That’s why they mention measures like “defect rate” and “bug severity”. Those measures are not currently being discussed here, and they should be.
They are trying to say that 100% error free is neither appropriate nor useful. It is a binary classification that throws away the important nuance.
That’s why they mention measures like “defect rate” and “bug severity”. Those measures are not currently being discussed here, and they should be.
> If that's the case, why do studies show that so many Excel spreadsheets have major errors in them?
Your point, which is completely true, is not incompatible with GP's statement.
Excel is ubiquitous in the corporate world and most spreasheet in the corporate world are completely full of errors everywhere.
Not just errors but also broken assumptions.
I've been tasked with porting a spreadsheet to a dedicated app because people noticed numbers were off and, oh the clusterfuck. Never again.
The world started making much more sense to me from the moment I realized most business decisions were taken based on powerpoint presentation containing numbers coming from broken Excel spreadsheets.
Your point, which is completely true, is not incompatible with GP's statement.
Excel is ubiquitous in the corporate world and most spreasheet in the corporate world are completely full of errors everywhere.
Not just errors but also broken assumptions.
I've been tasked with porting a spreadsheet to a dedicated app because people noticed numbers were off and, oh the clusterfuck. Never again.
The world started making much more sense to me from the moment I realized most business decisions were taken based on powerpoint presentation containing numbers coming from broken Excel spreadsheets.
Financials are auditable. Code is auditable. The fact that something can be audited doesn't mean it will be, or will be done well if done.
Now do software in general.
I totally agree with this. I've always found debugging Excel spreadsheets to be a real challenge.
I work in accountancy and while its possible to audit the output of the spreadsheet, (as I'm sure it's possible to audit the output in other domains) as an erstwhile Software Engineer I can't help but think it would be better if I could better verify the integrity of the spreadsheet itself. It's far too easy to introduce unnoticed errors.
Other people have different views on this but I love the idea of spreadsheets but I don't like any spreadsheet software. I think there's massive room for improvement. But if you were to ask me how to improve it specifically, I couldn't really pinpoint anything.
I had a go at doing something in this space to scratch a very specific itch but of course, it doesn't address any of my complaints here. Rather, it tried to tackle another of my complaints - the lack of good support for different number bases https://github.com/JetSetIlly/Ivycel/
I work in accountancy and while its possible to audit the output of the spreadsheet, (as I'm sure it's possible to audit the output in other domains) as an erstwhile Software Engineer I can't help but think it would be better if I could better verify the integrity of the spreadsheet itself. It's far too easy to introduce unnoticed errors.
Other people have different views on this but I love the idea of spreadsheets but I don't like any spreadsheet software. I think there's massive room for improvement. But if you were to ask me how to improve it specifically, I couldn't really pinpoint anything.
I had a go at doing something in this space to scratch a very specific itch but of course, it doesn't address any of my complaints here. Rather, it tried to tackle another of my complaints - the lack of good support for different number bases https://github.com/JetSetIlly/Ivycel/
Excel users can make mistakes, therefore Excel spreadsheets can't be audited? Is that your point?
My point is that if Excel spreadsheets can be audited, practically speaking, why are these major errors going unnoticed all the time?
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.
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.
> 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.
I don't think I can agree with this. The average codebase I see is pretty terrible readability-wise. Nasty levels of function nesting, tons of variation of behavior based on arguments passed into functions, etc. I assume the average Excel spreadsheet is also pretty nasty, but it has the advantage of having a debugger "built in" vs looking at the code generally without actually seeing the data flowing through it (e.g. who runs every code review they do through a debugger?).
I also think this ignores that a "traditional" program replacing Excel would still need to get data from somewhere, which commonly implies a SQL database or a data warehouse that speaks SQL these days, and complex SQL is itself NASTY to verify/fully grok through reading alone.
I don't think I can agree with this. The average codebase I see is pretty terrible readability-wise. Nasty levels of function nesting, tons of variation of behavior based on arguments passed into functions, etc. I assume the average Excel spreadsheet is also pretty nasty, but it has the advantage of having a debugger "built in" vs looking at the code generally without actually seeing the data flowing through it (e.g. who runs every code review they do through a debugger?).
I also think this ignores that a "traditional" program replacing Excel would still need to get data from somewhere, which commonly implies a SQL database or a data warehouse that speaks SQL these days, and complex SQL is itself NASTY to verify/fully grok through reading alone.
My main problems with checking spreadsheet code are:
1) Code formatting - spreadsheet formulae are generally presented all on one line with minimal spacing and no syntax highlighting. Any mildly complex formula should ideally be presented a) across multiple lines, b) with indenting to show function nesting depth, and c) in colour.
2) Copy and paste - spreadsheet formulae are generally copy-and-pasted every time they're used (i.e. on every row), rather than being defined once and referenced in each place they're used. Some spreadsheets are now good at highlighting if one formula is out of place in a column of otherwise-similar formulae, but it's hard to check if formulae are supposed to be "the same" in different columns, or different worksheets, or in different spreadsheet files.
1) Code formatting - spreadsheet formulae are generally presented all on one line with minimal spacing and no syntax highlighting. Any mildly complex formula should ideally be presented a) across multiple lines, b) with indenting to show function nesting depth, and c) in colour.
2) Copy and paste - spreadsheet formulae are generally copy-and-pasted every time they're used (i.e. on every row), rather than being defined once and referenced in each place they're used. Some spreadsheets are now good at highlighting if one formula is out of place in a column of otherwise-similar formulae, but it's hard to check if formulae are supposed to be "the same" in different columns, or different worksheets, or in different spreadsheet files.
I've been involved in at least a dozen audits during Series B/C fundraising periods, the bulk of which included financial models with forward-looking quarterly forecasts backed up with prior-quarter actual results.
Accounting audit usually involves accountants/CFO going through how the accounting system accounts are structured, and how those accounts get turned into the three financial statements (cash flow, income statement, balance sheet). You might have a unique accounting scenario where large expenses can be amortized over several periods, and an auditor will check how that reporting schedule was produced to net out what everyone is looking at on the financial statements. Maybe there was an acquisition that didn't quite pan out and there's an impairment charge that had material differences. Maybe your business collects cash upfront but reports deferred revenue. Maybe your company offers a product warranty so there's a non-trivial accrual schedule to consolidate warranty liability.
I worked at a company that convinced the SEC that it generated revenues from its published content over a 5-year period, allowing it to amortize expenses over that revenue-generating period while front-loading revenues over the first 18 months. Eventually the SEC changed the rules and expenses were expected to be reported in proportion to revenues.
There's a lot of ways those numbers can be put together, with a lot of different rules for how cash, revenue, and loss can be represented and disclosed. The kinds of errors I've seen encountered are less Excel formula errors, and more fundamental issues with account structures and how numbers are being strung together to reach what is reported.
The impression I've received is that what matters during the audit process is not if there are mistakes and errors, but if they lead to material changes that alter the trajectory of any decisions being made.
Accounting audit usually involves accountants/CFO going through how the accounting system accounts are structured, and how those accounts get turned into the three financial statements (cash flow, income statement, balance sheet). You might have a unique accounting scenario where large expenses can be amortized over several periods, and an auditor will check how that reporting schedule was produced to net out what everyone is looking at on the financial statements. Maybe there was an acquisition that didn't quite pan out and there's an impairment charge that had material differences. Maybe your business collects cash upfront but reports deferred revenue. Maybe your company offers a product warranty so there's a non-trivial accrual schedule to consolidate warranty liability.
I worked at a company that convinced the SEC that it generated revenues from its published content over a 5-year period, allowing it to amortize expenses over that revenue-generating period while front-loading revenues over the first 18 months. Eventually the SEC changed the rules and expenses were expected to be reported in proportion to revenues.
There's a lot of ways those numbers can be put together, with a lot of different rules for how cash, revenue, and loss can be represented and disclosed. The kinds of errors I've seen encountered are less Excel formula errors, and more fundamental issues with account structures and how numbers are being strung together to reach what is reported.
The impression I've received is that what matters during the audit process is not if there are mistakes and errors, but if they lead to material changes that alter the trajectory of any decisions being made.
OK, I can see I've been talking somewhat at cross-purposes to some other people in the thread. When the G*P commenter said:
> The killer feature of Excel for financial modelling, over 'proper' software, databases etc is portability and auditability.
...comparing Excel to "'proper' software", extolling Excel's "portability and auditability", I read that as highlighting Excel spreadsheets' ability to be audited as software.
https://en.wikipedia.org/wiki/Code_audit
i.e. the ability to inspect the "code" of a spreadsheet, to ensure it does what the authors think it does/want it to do, and that it conforms to any informal/internal guidelines of the organisation using it - the sort that "'proper' software" is subject to.
That seemed to me to be the meaning intended by the original comment in the thread?
> The killer feature of Excel for financial modelling, over 'proper' software, databases etc is portability and auditability.
...comparing Excel to "'proper' software", extolling Excel's "portability and auditability", I read that as highlighting Excel spreadsheets' ability to be audited as software.
https://en.wikipedia.org/wiki/Code_audit
i.e. the ability to inspect the "code" of a spreadsheet, to ensure it does what the authors think it does/want it to do, and that it conforms to any informal/internal guidelines of the organisation using it - the sort that "'proper' software" is subject to.
That seemed to me to be the meaning intended by the original comment in the thread?
The kind of professionals doing audit's against Excel spreadsheets are not auditing the "code", they're auditing the methodology used to produce the results being audited.
I've also been through several code audits, and other than sharing the "word" audit they're not the same thing. Audit in this context is the ability to follow how some numbers were derived, and to check how the work was done. It's so that the 3rd party that hired them can confirm the numbers a 1st party are showing are what they say they are (and if not, are they close enough).
Accountants are confirming things comply with GAAP or IFRS, and pointing things out when they don't and asking for clarification. They'll be checking that liabilities were properly structured, and reflected in how profit was derived. They'll be reviewing deferred revenue schedules to make sure next year's pre-paid subscription revenue isn't recognized in Q4.
A financial auditor is going to be looking at the assumptions of the forecast, and working backwards to confirm the methodology. They'll confirm that Q4 2026 projections used the prior years average multiplied by quarterly constant. Or they'll find a results from an ARIMA/Prophet model with notes to "see X". Maybe they'll catch an Excel formula error or 2, but they'll unlikely mean much compared to what else could be wrong.
I've also been through several code audits, and other than sharing the "word" audit they're not the same thing. Audit in this context is the ability to follow how some numbers were derived, and to check how the work was done. It's so that the 3rd party that hired them can confirm the numbers a 1st party are showing are what they say they are (and if not, are they close enough).
Accountants are confirming things comply with GAAP or IFRS, and pointing things out when they don't and asking for clarification. They'll be checking that liabilities were properly structured, and reflected in how profit was derived. They'll be reviewing deferred revenue schedules to make sure next year's pre-paid subscription revenue isn't recognized in Q4.
A financial auditor is going to be looking at the assumptions of the forecast, and working backwards to confirm the methodology. They'll confirm that Q4 2026 projections used the prior years average multiplied by quarterly constant. Or they'll find a results from an ARIMA/Prophet model with notes to "see X". Maybe they'll catch an Excel formula error or 2, but they'll unlikely mean much compared to what else could be wrong.
Because not all spreadsheets are audited? Just because they can doesn't mean they are. Also a financial audit is very different in what it is looking for, compared to a cyber security audit, for instance. They are looking to prove the accounts show a true and fair view of the company, not 'are your formulas perfect'. They are more likely to copy out your raw data and run their own analysis.
Answering your edit, not all spreadsheets are opaque either. We design ours to be audited.
Answering your edit, not all spreadsheets are opaque either. We design ours to be audited.
Sounds like you work well outside of the domain.
Auditors don’t show up to critique your formulas. They are looking at business processes, which means usually the data that flows between things. If it gets to the point where they are digging that deep, they have a finding and are trying to assess the severity.
Software, including major business systems are often fucked up. There are major companies using RPA software to robotically use excel to correct some fubar in Oracle financials that wont get fixed for a few years.
The beauty of excel is that the business speaks it.
Auditors don’t show up to critique your formulas. They are looking at business processes, which means usually the data that flows between things. If it gets to the point where they are digging that deep, they have a finding and are trying to assess the severity.
Software, including major business systems are often fucked up. There are major companies using RPA software to robotically use excel to correct some fubar in Oracle financials that wont get fixed for a few years.
The beauty of excel is that the business speaks it.
[deleted]
I wonder if something like Lotus Improv would be easier to audit.
Software is both testable and auditable, and yet, bugs still exist! Even in open-source code which is also freely and publicly reviewable.
The ability to audit doesn't necessarily mean that the "code" in a spreadsheet is easy to read, only that it is easy to see...
And it's not just a matter of functionality: there's an enormous difference in performance. I've had to push the limits of Excel to do data analysis and visualization on huge spreadsheets with complex lookup formulas. It worked great. Then I tried to import into Google Sheets to share with colleagues and it completely choked. Like I let it churn for hours and it never finished recalculating. Google Sheets is "good enough" for basic, simple stuff but for anything more it's a real productivity killer.
This. I had similar experiences with LibreOffice. It can choke on what you'd think were pretty mundane and reasonably sized things. I imported a CSV file of 15K lines once and it used all available memory on my PC doing it. The optimization that goes into Excel is one of those "unsung hero" things that doesn't get a lot of glory but it is clutch day in and day out.
I worked in a place where excel was used for ad-hoc calculations. We became a Google shop.
Sheets was a piece of junk compared to excel. Anyone who did any real work rather than just looking at a spreadsheet or using a template got Excel back in about a week.
Sheets was a piece of junk compared to excel. Anyone who did any real work rather than just looking at a spreadsheet or using a template got Excel back in about a week.
Google Sheets does struggle past a certain size.
For Spreadsheets-are-all-you-need (GPT2 Small implemented in Spreadsheet, ~1.25GB Excel file, 124M parameters), I have only been able to get the complete model working in Excel.
In Google Sheets, I've only been able to get it to implement a single layer out of the 12 in the model. And there's no way it can handle the embedding matrix. And it randomly quit during tokenization.
That being said, I am a fan of both Excel and Google Sheets. In Google Sheets the formulas are easier to read, and for teaching my class, it's great because students and I can be in the same sheet at the same time during a lesson.
I also tried LibreOffice briefly. While it could open the Excel file, it was unable to save it (it crashed during the save process).
For Spreadsheets-are-all-you-need (GPT2 Small implemented in Spreadsheet, ~1.25GB Excel file, 124M parameters), I have only been able to get the complete model working in Excel.
In Google Sheets, I've only been able to get it to implement a single layer out of the 12 in the model. And there's no way it can handle the embedding matrix. And it randomly quit during tokenization.
That being said, I am a fan of both Excel and Google Sheets. In Google Sheets the formulas are easier to read, and for teaching my class, it's great because students and I can be in the same sheet at the same time during a lesson.
I also tried LibreOffice briefly. While it could open the Excel file, it was unable to save it (it crashed during the save process).
In my case, it doesn't crash. But there tends to be visual formatting issues.
I remember my attempts to use numbers on a mac to pull up some spreadsheets.
It was SO. IMPOSSIBLY. SLOW.
Maybe it's different now with M4 macs, but I still remember a friend telling me that response times above 1/10th of a second were not interactive anymore. Made total sense after that.
It was SO. IMPOSSIBLY. SLOW.
Maybe it's different now with M4 macs, but I still remember a friend telling me that response times above 1/10th of a second were not interactive anymore. Made total sense after that.
It's unbearably slow even opening and filtering a small CSV file (100s of rows).
The reason of excel excelling in being everywhere, is mostly that it has an easy learning curve and it presents itself in the form of 2D tables, like kids have learning to understand early in primary school. Also its VBA macros make it easy to start programming.
If your ERP outputs are in Excel, I guess pdf or csv or html could have been chosen as well, since those are also constants in the world?
If your ERP outputs are in Excel, I guess pdf or csv or html could have been chosen as well, since those are also constants in the world?
These are true, but it's not the reason it's so successful.
It's the original agile, functional programming environment. Code iteration and basic testing is done in microseconds.
I remember laughing very hard when someone excitedly told me about REPL in python, like it was a new idea.
It's the original agile, functional programming environment. Code iteration and basic testing is done in microseconds.
I remember laughing very hard when someone excitedly told me about REPL in python, like it was a new idea.
REPL is far older than Excel, it's from the 1960s.
neither of those are useful for the next stage of analysis.
Csv is much more useful than Excel.
Pdf is much less useful.
Pdf is much less useful.
CSV is undefined and the edge cases are very ugly. It is compatible until the import fails silently and makes a mess of the data.
I also cannot contain formulas. Only data.
If your process can read and write to Excel it is a much better defined format.
I also cannot contain formulas. Only data.
If your process can read and write to Excel it is a much better defined format.
CSV is fully defined in RFC 4180. Of course that standard is only informative and some vendors don't implement it correctly.
https://www.ietf.org/rfc/rfc4180.txt
https://www.ietf.org/rfc/rfc4180.txt
CSV is a simple data interchange format. Better than excel in that context.
PDF is the canonical way to preserve formatting where that is important. A court document electronically filed in PDF in 1999 is identically rendered today. The source .doc or WordPerfect file is not.
PDF is the canonical way to preserve formatting where that is important. A court document electronically filed in PDF in 1999 is identically rendered today. The source .doc or WordPerfect file is not.
Only if the thing consuming it can consume formulas.
can you make graphs in a CSV?
Not exactly, I like to graph "xSV" data as it is streaming in to the PC, with processing before displaying and filling the cells with the filtered data. You can choose which functions you want to apply before data hits the cells and let the cells do their magic after that. Pretty much a real-time live graph, other than a little latency.
After data collection (or during), then output can be made in any format you would like. In addition to what anybody would want to print right off the spreadsheet.
The XLS(X) file forms a database and UI, contains a copy of the input macros and output macros, and you save the whole thing every time which backs it all up (over and over and over again) in a form that anybody can open anywhere with a PC that only has Windows & Office. And whoever opens it will be right up to speed as good as they can be with whatever abilities they have using Excel alone.
After data collection (or during), then output can be made in any format you would like. In addition to what anybody would want to print right off the spreadsheet.
The XLS(X) file forms a database and UI, contains a copy of the input macros and output macros, and you save the whole thing every time which backs it all up (over and over and over again) in a form that anybody can open anywhere with a PC that only has Windows & Office. And whoever opens it will be right up to speed as good as they can be with whatever abilities they have using Excel alone.
I found different versions of Excel, and Excel in general, are less consistent ingesting XLS(X) files than tabulated text or well-crafted CSV's.
The real problem isn’t with Excel itself. The problem is VBA and even Microsoft has been trying to kill it with JavaScript and future python support. I don’t feel that even MS can kill VBA since it’s so ubiquitous on Excel into the day that the majority of users transition to Excel online.
If MSFT are serious about this, they need to make migration easier. Right now they half heartedly point you at javascript and excel plugins and walk away. When Record Macro gives you the option of recording in JavaScript, not VBA, then we'll talk.
What is wrong with VBA? Aside from a few syntax quirks, like no short circuits in if statements, it is a very easy language to learn and use. And, the syntax hinting (IntelliSense?) is incredible.
It would be easier if they simply port their VBA runtime to WASM and call it a day.
I'm using Google Sheets instead of Excel since a few years, and the only feature I miss is Solver.
It's almost too easy to hit up https://sheets.new whenever I get an idea.
Having to wait for Excel to load up every time would be a killer.
I also really like Google Forms, and use it for tracking things like my piano practice time[0]. The page loads instantly and it only takes 6-7 seconds to log a new time.
https://i.imgur.com/xK6tnJe.png
I don't think Excel offers anything like this.
Having to wait for Excel to load up every time would be a killer.
I also really like Google Forms, and use it for tracking things like my piano practice time[0]. The page loads instantly and it only takes 6-7 seconds to log a new time.
https://i.imgur.com/xK6tnJe.png
I don't think Excel offers anything like this.
I think your computer may have problems. I have a 5 year old Dell Latitude and Excel loads with a new sheet in under 2 seconds from cold. I have the excel on my taskbar so even triggering the launch is Win+2 and quick.
Excel on Mac is another ball of wax though. Bit of a dog, that.
Excel on Mac is another ball of wax though. Bit of a dog, that.
Likely a corporate pc with 20 different security products slowing it down
10 years ago I joined a consulting company as a data science intern. I arrived at work with my MacBook. I learned about excel in courses but had never used in my daily life: I use csv and SQLite for "data-heavy" cases and Numbers for intuitive cases (never coded inside it). When someone shares an excel sheet with me, I open with Numbers with no problem.
On day 1 I realized my work was to deal with several excel sheets of 10~50MB, with huge amount of VBA scripts, rule-based highlighting, charts... They even wrote an internally used extension for those files. Numbers could not handle and crashed.
I need Excel. I asked if I could borrow a PC laptop from the company, no, that's not for interns. I need to bring my own device. I asked if they would pay for Microsoft Office to get installed on my personal MacBook. The answer was obvious, what are you thinking? I had to manage to get Excel for myself, while the full salary they paid me was not enough to cover a license.
I left consulting after that experience and end up working as a "real" data scientist. Nothing like that happened ever. I collaborate with colleagues using different IDEs/editors everyday. If an accountant joins us and tells me notepad is all you need, I would highly respect his choice and continue with my editor. We don't need to argue, our codebase is not locked in any tools.
On day 1 I realized my work was to deal with several excel sheets of 10~50MB, with huge amount of VBA scripts, rule-based highlighting, charts... They even wrote an internally used extension for those files. Numbers could not handle and crashed.
I need Excel. I asked if I could borrow a PC laptop from the company, no, that's not for interns. I need to bring my own device. I asked if they would pay for Microsoft Office to get installed on my personal MacBook. The answer was obvious, what are you thinking? I had to manage to get Excel for myself, while the full salary they paid me was not enough to cover a license.
I left consulting after that experience and end up working as a "real" data scientist. Nothing like that happened ever. I collaborate with colleagues using different IDEs/editors everyday. If an accountant joins us and tells me notepad is all you need, I would highly respect his choice and continue with my editor. We don't need to argue, our codebase is not locked in any tools.
I keep saying exactly the same thing for nearly 20 years. SMEs, Fortune 2000, and even Governments. The world runs on Excel. And it is perhaps the most important piece of software, more so than Linux or Windows.
You could change ERP, you could change CRM. But there are always something important stored in Excel spreadsheets that no one wants to touch or transfer to something else.
You could change ERP, you could change CRM. But there are always something important stored in Excel spreadsheets that no one wants to touch or transfer to something else.
“Entrenched” isn’t the same as “very good”
This hits home. We upgraded a very massive Excel-based model to the peak of our best practice. Proper split in requirements vs. implementation, a separate data quality layer, model validation on the model, Ze Kloud, etc. Turns out accountants don’t grok model validation and I am still explaining imputation on individual data fields to auditors expecting each individual value to be user inputted somewhere. Waving IAS8 in front of your auditor doesn’t help since you are threading on their expertise and that gets messy. Excel models turn out to be multi headed dragons, but you can mail a spreadsheet with five example cases and get by.
Excel problems and errors are everywhere too.
Especially when data imports are necessary.
I don’t want to know how many decisions are made based on faulty Excel spreadsheets.
I don’t want to know how many decisions are made based on faulty Excel spreadsheets.
>I don’t want to know how many decisions are made based on faulty Excel spreadsheets.
And people are aware of it but they don't know where the faults are and need to go forward anyway.
So they must act as if nothing could be wrong, and if something does come up later on it can be treated as a complete surprise to everyone concerned.
With that kind of acting, how about how far the bar has been lowered on even more critical decisions? :\
And people are aware of it but they don't know where the faults are and need to go forward anyway.
So they must act as if nothing could be wrong, and if something does come up later on it can be treated as a complete surprise to everyone concerned.
With that kind of acting, how about how far the bar has been lowered on even more critical decisions? :\
I need you to explain why those other tools are like notepad instead of just another IDE.
Because if you tell me I could get my job done with a different IDE, I would say yes that is correct.
(And they use pretty much the same mess of a formula language. I reject the idea that using not-excel is like using BASIC on top of using notepad.)
Because if you tell me I could get my job done with a different IDE, I would say yes that is correct.
(And they use pretty much the same mess of a formula language. I reject the idea that using not-excel is like using BASIC on top of using notepad.)
And if my IDE made it harder for me so save a file to it could nudge me into saving it into its cloud I would definitely run to other IDEs.
The auditors use it, the CFO expects it, it’s all the interns know. These are reasons to have to use it, not to like it.
At best it’s an arranged marriage, at worst it’s Stockholme syndrome.
At best it’s an arranged marriage, at worst it’s Stockholme syndrome.
Its the same for many aspects of engineering, equally applies. Thank you
So by your logic, if the entire audit world used Numbers, you would be using Numbers. That isn’t remotely close to the rationale for why we don’t code BASIC in Notepad and is probably the reason why people here find Excel to be a less than ideal choice. We use the right tool for the job, not the tool that all of the industry uses because we would be screwed otherwise.
Those feelings are nice, but Excel in most context is just a liability. The intersection where a spreadsheet is the right tool for the job, and the job is performed by someone who doesn't have many options is pretty small.
In business cases, the risk with home grown spreadsheet 'workflows' is pretty big, and in home usage cases you don't really need more than just a basic spreadsheet. The intersection is perhaps where you have some offline data, cannot write a program as fast as you can use a spreadsheet and there is no risk associated with taking the data and workflow out of a guarded environment.
The same can be said for things like word processing, when you need a book or a paper, you might be in need of typesetting rather than a program that tries to do everything but at a level a novice can use it. You're not going to get a paper or an offset printed book from a text editor. Perhaps if you self-publish a PDF that doesn't need to meet any requirements you can get away with an all-in-one DIY solution. But the time period where that was relevant (around the late 90's) has come and gone.
Let's not stop there, the same can be applied to someone doing some Apps Script, Python notebooks or other solo yolo work, because it felt faster or more productive to them. Surprise! Your cowboy behaviour doesn't actually work at scale, doesn't fit in a shared system and doesn't work in production. But you wanted to be quick and 'get it done'. Instead you waste your own time and everyone else's time, and didn't deliver something that works. (at work; and that includes "but I have done it this way for 1000 years! - doing it wrong a lot doesn't make it less wrong)
But say you want to do some budgeting at home, and all you need is some boxes to type numbers in, then yes, why not use a spreadsheet. But that's not what people celebrate. People celebrate running a company with 100's of jobs on a single spreadsheet, and probably only because it hasn't gone horribly wrong yet. And then there's the real bad scenario, a specialised system (say, an ERP or PIM or CMS) where you pull the data out, do the thing in excel because you didn't want to learn how to use the system and you happen to have written some lists of numbers in excel once and therefore it is now your universal hammer. Good for you, bad for your department or entire business unit because you just broke out of a shared workflow because you thought you knew better which tends to have universally bad consequences.
Excel specifically is an example of "they just don't know any better", just like the everything-is-a-nail example (where Excel is the hammer and every problem looks like a spreadsheet). You could replace Excel with something else and it would still be the same problem (i.e. replacing Excel with Word in scenarios where people want to send someone an image that is on their clipboard - they know they can paste it in Word, so that is what they do and you on the receiving end get a grainy compressed image in a word document). It's not that the sending and receiving didn't work at all, or that the software or the people are bad, it's just a really shitty "solution" that shouldn't be glorified and be seen as the failure to educate that it is.
You can enjoy it as much as you want on your own time. That doesn't make it the great universal fit you think it is.
In business cases, the risk with home grown spreadsheet 'workflows' is pretty big, and in home usage cases you don't really need more than just a basic spreadsheet. The intersection is perhaps where you have some offline data, cannot write a program as fast as you can use a spreadsheet and there is no risk associated with taking the data and workflow out of a guarded environment.
The same can be said for things like word processing, when you need a book or a paper, you might be in need of typesetting rather than a program that tries to do everything but at a level a novice can use it. You're not going to get a paper or an offset printed book from a text editor. Perhaps if you self-publish a PDF that doesn't need to meet any requirements you can get away with an all-in-one DIY solution. But the time period where that was relevant (around the late 90's) has come and gone.
Let's not stop there, the same can be applied to someone doing some Apps Script, Python notebooks or other solo yolo work, because it felt faster or more productive to them. Surprise! Your cowboy behaviour doesn't actually work at scale, doesn't fit in a shared system and doesn't work in production. But you wanted to be quick and 'get it done'. Instead you waste your own time and everyone else's time, and didn't deliver something that works. (at work; and that includes "but I have done it this way for 1000 years! - doing it wrong a lot doesn't make it less wrong)
But say you want to do some budgeting at home, and all you need is some boxes to type numbers in, then yes, why not use a spreadsheet. But that's not what people celebrate. People celebrate running a company with 100's of jobs on a single spreadsheet, and probably only because it hasn't gone horribly wrong yet. And then there's the real bad scenario, a specialised system (say, an ERP or PIM or CMS) where you pull the data out, do the thing in excel because you didn't want to learn how to use the system and you happen to have written some lists of numbers in excel once and therefore it is now your universal hammer. Good for you, bad for your department or entire business unit because you just broke out of a shared workflow because you thought you knew better which tends to have universally bad consequences.
Excel specifically is an example of "they just don't know any better", just like the everything-is-a-nail example (where Excel is the hammer and every problem looks like a spreadsheet). You could replace Excel with something else and it would still be the same problem (i.e. replacing Excel with Word in scenarios where people want to send someone an image that is on their clipboard - they know they can paste it in Word, so that is what they do and you on the receiving end get a grainy compressed image in a word document). It's not that the sending and receiving didn't work at all, or that the software or the people are bad, it's just a really shitty "solution" that shouldn't be glorified and be seen as the failure to educate that it is.
You can enjoy it as much as you want on your own time. That doesn't make it the great universal fit you think it is.
I think you misunderstand 'workflows' in business. This is not a case of ingesting a large amount of data, transform, analyse etc.
A normal finance team gets constant one off requests for information. Download something from the ERP, lookup against something else, pivot it by department. Then you get a follow up for the same but with x excluded, but they need it in 10 minutes before a meeting. Excel is great for that.
Then there are the dozens of files behind accounting records. Take a Fixed Asset Register (since it is at the top of the balance sheet), a list of your assets and their depreciation schedule. Maybe your ERP doesn't have one, or your company didn't buy that module, or you have a special class off asset that doesn't fit in it. Maybe they coded it for one country, but in your country the rules are different, so it ends up in Excel.
Then maybe you have a bank account and you have cheques that are posted to your ledger but have not cleared the actual bank yet. Then you have items on your real account that you couldn't post yet, maybe someone paid you with no reference. So you keep a little Excel reconciliation to check.
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
Then you have all the things that belong in this accounting period but haven't been billed yet, so you have a running list of accruals and when they will reverse. Then you have all the things that are posted in this period but relate to later periods, so you keep a prepayments file. Maybe both of these spit out a journal to upload back to the ERP and reconcile the balance.
Then you get a download of the payroll for the month, but you need to rearrange it into net pay, gross pay, taxes paid by the employee, taxes paid by the employer, pension contributions... then you have to split it by cost centre too. This could be coded, but it is different in every country... and the cost centres keep changing, and the analysis head office wants keeps changing... so it goes in Excel.
Then I want to verify that the system posted the correct absorption to inventory, so I paste in an inventory report and a TB and last month's reconciliation updates.
I can code, but I can't maintain 100 pieces of software that change all the time. I also need all the people in the chain to be able to follow it....
And yes, finance people know how to apply the famous 'checks and balances' to keep out most classes of mistakes....and to detect the same mistakes made by the engineered 'proper software' we have to work with.
A normal finance team gets constant one off requests for information. Download something from the ERP, lookup against something else, pivot it by department. Then you get a follow up for the same but with x excluded, but they need it in 10 minutes before a meeting. Excel is great for that.
Then there are the dozens of files behind accounting records. Take a Fixed Asset Register (since it is at the top of the balance sheet), a list of your assets and their depreciation schedule. Maybe your ERP doesn't have one, or your company didn't buy that module, or you have a special class off asset that doesn't fit in it. Maybe they coded it for one country, but in your country the rules are different, so it ends up in Excel.
Then maybe you have a bank account and you have cheques that are posted to your ledger but have not cleared the actual bank yet. Then you have items on your real account that you couldn't post yet, maybe someone paid you with no reference. So you keep a little Excel reconciliation to check.
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
Then you have all the things that belong in this accounting period but haven't been billed yet, so you have a running list of accruals and when they will reverse. Then you have all the things that are posted in this period but relate to later periods, so you keep a prepayments file. Maybe both of these spit out a journal to upload back to the ERP and reconcile the balance.
Then you get a download of the payroll for the month, but you need to rearrange it into net pay, gross pay, taxes paid by the employee, taxes paid by the employer, pension contributions... then you have to split it by cost centre too. This could be coded, but it is different in every country... and the cost centres keep changing, and the analysis head office wants keeps changing... so it goes in Excel.
Then I want to verify that the system posted the correct absorption to inventory, so I paste in an inventory report and a TB and last month's reconciliation updates.
I can code, but I can't maintain 100 pieces of software that change all the time. I also need all the people in the chain to be able to follow it....
And yes, finance people know how to apply the famous 'checks and balances' to keep out most classes of mistakes....and to detect the same mistakes made by the engineered 'proper software' we have to work with.
I doubt I misunderstand it since this is what I get paid for. I'm also not suggesting this is a case of large data, ETL or anything like that. (what I'm writing about is people using it for that anyway which is what we have other systems for and they should not be doing 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.
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.
> While we primarily deal with Dynamics (AX and 365), pretty much everything fits in there
I don't have much experience with Dynamics. My experience is mostly Oracle, SAP and Netsuite plus some bespoke.
I agree modern systems are very flexible. Everything could fit in there eventually if you are willing to pay, and willing to wait. But reporting can't wait.
The company I work for has 1000 factories, many sales offices. They use many different ERPs. I heard our division has 23! We were all acquired at different times, . My unit was acquired by a group that subsequently sold a part of itself. They are constantly trying to standardise on one system, but then acquire something else with more different systems. We get around this by using a consolidation system. Export, transform, load of only top line metrics..All via Excel, which is fully integrated into the consolidation system. The consolidation doesn't preserve line level data, so if someone needs it they have to ask for a spreadsheet. The IT just never catches up with the business.
The last mega Corp I worked for was simpler and more standardised, but still used different ERPs in different divisions. We were acquired by a group that was acquired by mega Corp, because they wanted a product a different division made. We were shoehorned in. We were on SAP already, but had to move to theirs...took 18 months to get to us. In the mean time...we used a consolidation system... via Excel
I don't have much experience with Dynamics. My experience is mostly Oracle, SAP and Netsuite plus some bespoke.
I agree modern systems are very flexible. Everything could fit in there eventually if you are willing to pay, and willing to wait. But reporting can't wait.
The company I work for has 1000 factories, many sales offices. They use many different ERPs. I heard our division has 23! We were all acquired at different times, . My unit was acquired by a group that subsequently sold a part of itself. They are constantly trying to standardise on one system, but then acquire something else with more different systems. We get around this by using a consolidation system. Export, transform, load of only top line metrics..All via Excel, which is fully integrated into the consolidation system. The consolidation doesn't preserve line level data, so if someone needs it they have to ask for a spreadsheet. The IT just never catches up with the business.
The last mega Corp I worked for was simpler and more standardised, but still used different ERPs in different divisions. We were acquired by a group that was acquired by mega Corp, because they wanted a product a different division made. We were shoehorned in. We were on SAP already, but had to move to theirs...took 18 months to get to us. In the mean time...we used a consolidation system... via Excel
We also consolidated from multiple systems but we never had that many in parallel, we always were finished in time before adding/splitting the next set.
The previous setup was all SAP, but that was too slow and we couldn't get the change rate we wanted. That was over 10 years ago, and AX had different issues but at least nothing the end-users have to deal with.
Besides AX and 365 we have 3 more, as well as some legacy processes still using MSBI, but all of the data going in and data going out is captured (either in Databricks or in our integration systems) which means that reporting and things like invoicing, banking, purchasing etc doesn't really care much about the underlying ERP. The ERP core team of course does, but the days where most of the work was serving direct business day-to-day needs are long gone, it's mostly edge cases and keeping the ERP in line with business changes.
All the metrics are processed in spark and exposed to both Tableau (together with an SQL Warehouse that lets you access all the individual data as well), and Thanos. So if a technical team wants to do some deeper analysis side-by-side with technical data that's possible too (which is great since they tend to be more comfortable with that vs. tableau). It's pretty nice to have financial data, WSSI data, GTM data and service deployment data overlaid so you can see the direct impact of everything on everything. (even if the resolution for some data is not the same - zoom out enough and you get very actionable insights)
Perhaps one of the differences is what we are mainly in retail, warehousing and logistics, when we buy a product or services business we tend to ditch everything except the data and the people. Our data engineering team takes care of the capture and transformation and the respective specialised process teams (CRM, ERP, PIM, fulfilment etc) coordinate from the business, legal and operational perspective. There will be a cutoff date and depending on the size we'll either have had a realtime streaming period (CDC style mainly) or do a one-off snapshot of the business and do it in one go.
For our business users it means they won't need to go to a secondary system to get the 'other' data; instead, the data comes to them.
I'm not sure why this method has not failed yet, I suspect it's because some M&A strategy components outline the cost/benefit clear enough to not have us integrate something that is not integrate-able.
The previous setup was all SAP, but that was too slow and we couldn't get the change rate we wanted. That was over 10 years ago, and AX had different issues but at least nothing the end-users have to deal with.
Besides AX and 365 we have 3 more, as well as some legacy processes still using MSBI, but all of the data going in and data going out is captured (either in Databricks or in our integration systems) which means that reporting and things like invoicing, banking, purchasing etc doesn't really care much about the underlying ERP. The ERP core team of course does, but the days where most of the work was serving direct business day-to-day needs are long gone, it's mostly edge cases and keeping the ERP in line with business changes.
All the metrics are processed in spark and exposed to both Tableau (together with an SQL Warehouse that lets you access all the individual data as well), and Thanos. So if a technical team wants to do some deeper analysis side-by-side with technical data that's possible too (which is great since they tend to be more comfortable with that vs. tableau). It's pretty nice to have financial data, WSSI data, GTM data and service deployment data overlaid so you can see the direct impact of everything on everything. (even if the resolution for some data is not the same - zoom out enough and you get very actionable insights)
Perhaps one of the differences is what we are mainly in retail, warehousing and logistics, when we buy a product or services business we tend to ditch everything except the data and the people. Our data engineering team takes care of the capture and transformation and the respective specialised process teams (CRM, ERP, PIM, fulfilment etc) coordinate from the business, legal and operational perspective. There will be a cutoff date and depending on the size we'll either have had a realtime streaming period (CDC style mainly) or do a one-off snapshot of the business and do it in one go.
For our business users it means they won't need to go to a secondary system to get the 'other' data; instead, the data comes to them.
I'm not sure why this method has not failed yet, I suspect it's because some M&A strategy components outline the cost/benefit clear enough to not have us integrate something that is not integrate-able.
>Perhaps one of the differences is what we are mainly in retail, warehousing and logistics
You nailed it. At a previous firm (when I was in charge of ERP as well) we took over these kind of firms and moved them into our ERP either immediately or after a few weeks.
Manufacturing is orders of magnitude more complex. BOMS, Routings, all the raw and intermediate level skus, interfacing with the shop floor equipment. The much more complex accounts, many more people to train in more specialisms. MRP is so much more complex, planning is more complex.
Then with our 1000s of business units... the Politics is so much more complex too
You nailed it. At a previous firm (when I was in charge of ERP as well) we took over these kind of firms and moved them into our ERP either immediately or after a few weeks.
Manufacturing is orders of magnitude more complex. BOMS, Routings, all the raw and intermediate level skus, interfacing with the shop floor equipment. The much more complex accounts, many more people to train in more specialisms. MRP is so much more complex, planning is more complex.
Then with our 1000s of business units... the Politics is so much more complex too
I short in many places the computer is still a human
Write a piece of software that ends Excel’s dominance and then I will take your opinion seriously.
I hate Excel for many reasons but it is king for a reason.
I hate Excel for many reasons but it is king for a reason.
Excel is king of cancer that you’ll implore to cut out once you realize it slowly kills your business. A perfect trap for novice entrepreneurs.
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.
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.
How did you fix the user habits in the end?
I don’t think it’s fixable. Excel enables chaotic “development” and it just happens. In the end we either left them with a system they ordered or bailed out cause it wasn’t worth it.
Edit: to clear misunderstandings, I didn’t fix their spreadsheets. I extracted knowledge and processes from there and from users and built a new system after discussing how it all and their ideas check together.
Edit: to clear misunderstandings, I didn’t fix their spreadsheets. I extracted knowledge and processes from there and from users and built a new system after discussing how it all and their ideas check together.
And I'd bet that after you left, your system was ignored or fell apart while those "chaotic" employees with their spreadsheets just kept chugging along fine.
Not sure why you’re assuming the worst of me here.
a) because you yourself wrote "sometimes we just failed" and "I don't think it's fixable", and
b) because in many years of corporate experience, the vast majority of systems built with the intention of replacing Excel processes fail to achieve that goal.
It is true that knowledge workers are often disorganized and messy - in large part, because actual business is also messy and changes very quickly. When you start with the attitude of "unfucking" and "sheer amount of crap", it's obvious that you actually aren't respectful and aware of the actual day-to-day demands of business, their bosses, presentation requirements, messy input sources, etc. Pure, testable code may be more elegant but it simply is not as flexible and UI-friendly as Excel, which is a large part of why these types of projects fail at such a high rate.
b) because in many years of corporate experience, the vast majority of systems built with the intention of replacing Excel processes fail to achieve that goal.
It is true that knowledge workers are often disorganized and messy - in large part, because actual business is also messy and changes very quickly. When you start with the attitude of "unfucking" and "sheer amount of crap", it's obvious that you actually aren't respectful and aware of the actual day-to-day demands of business, their bosses, presentation requirements, messy input sources, etc. Pure, testable code may be more elegant but it simply is not as flexible and UI-friendly as Excel, which is a large part of why these types of projects fail at such a high rate.
I am not respectful of excel at all, true. I could see your perspective, if it wasn’t a client who comes by itself(!) begging to do something with their spreadsheets cause key roles spend all day maintaining these, blocking further growth or mergers. Maybe I should not have called it crap out if respect to a client, but that’s what it was from the design pov, no reason to spare a word. I didn’t like it cause no one likes to dig in such sort of legacy. You treat the failure rate as an excel good indicator, well that may seem true until you get yet another call for help. It’s a failure rate of excel. I agree that we should have just bailed out by default and left them to sales sharks. At some point that’s what I did basically, said no to yet another “project”, cause these were crappy low hanging fruits that no one else wanted to deal with, not interesting jobs. Idk how it all assembles into “excel good” in some minds. As if companies just called integrators out of boredom because everything they’ve built in excel works.
You're saying Excel failed, when the work was mostly getting done, if inefficiently.
You showed up, unburdened by Excel, and soon quit ("bailed out" -- your words) because the projects were "crappy", "not interesting", "no one wanted to deal with". Yea, boring, crappy projects are a big, but essential part of business!
Lets be clear, YOU failed. Processes built upon Excel are often messy and inefficient, that's well-established, but just like in this example, attempting to replicate the processes without using Excel often implodes entirely.
You showed up, unburdened by Excel, and soon quit ("bailed out" -- your words) because the projects were "crappy", "not interesting", "no one wanted to deal with". Yea, boring, crappy projects are a big, but essential part of business!
Lets be clear, YOU failed. Processes built upon Excel are often messy and inefficient, that's well-established, but just like in this example, attempting to replicate the processes without using Excel often implodes entirely.
My success rate was around 2/3. That after I finished they returned to excel is your unfounded assumption (also demonstratively ignorant of what it takes).
Anyway, if you advise your clients to build on excel, I wish them luck, and wish you, when they fail to grow or simply sustain, to be successful in explaining them that it’s alright and integrators bad and they must just continue. Cause clearly this strategy works for you somehow. Make it work for them with the same energy as here and it’s done.
Anyway, if you advise your clients to build on excel, I wish them luck, and wish you, when they fail to grow or simply sustain, to be successful in explaining them that it’s alright and integrators bad and they must just continue. Cause clearly this strategy works for you somehow. Make it work for them with the same energy as here and it’s done.
Which 'opinion' would that be. The one where I write about anecdotes from the real world?
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.
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.
That all iterate too slowly and don’t put the development in the hands of the people doing the job.
Excel is near universal and flexible. It’s not a hammer. It’s a swiss army knife.
Excel is near universal and flexible. It’s not a hammer. It’s a swiss army knife.
You make it sound like their job is development (it's not).
If your job is to manage legal cases, you have no business writing case management software. That includes writing it in excel.
The same goes for collaborating with 100 people outside of your team, they are not going to keep tracking your personal DIY projects, they work with a common infrastructure so it's actually feasible to work instead of being busy playing engineer all day.
If your job is to manage legal cases, you have no business writing case management software. That includes writing it in excel.
The same goes for collaborating with 100 people outside of your team, they are not going to keep tracking your personal DIY projects, they work with a common infrastructure so it's actually feasible to work instead of being busy playing engineer all day.
Except without a way to get the computer to behave the way they want they have an arm strung behind their back in the modern economy.
EDIT: I think my experience could likely be in a situation very different to yours. Thinking about it more deeply I am describing an org up to its neck in tech debt and in a changing market where regulation is tighter than ever.
So, I think the pathologies are definitely more specific than universal.
EDIT: I think my experience could likely be in a situation very different to yours. Thinking about it more deeply I am describing an org up to its neck in tech debt and in a changing market where regulation is tighter than ever.
So, I think the pathologies are definitely more specific than universal.
That's not what our users tell us, and we're beating the competition so I guess you're either wrong or not familiar with the market we're in.
>If your job is to manage legal cases, you have no business writing case management software. That includes writing it in excel.
So true, but not everybody runs a company like it was a business :\
You may have to turn over every rock, but you just might find some bureaucracy "occasionally".
If your job is to manage X cases which have traditionally been done without a computer, you have the greatest advantage if you can outperform your peers when they don't have a computer either.
If X case management software is then adopted, there will once again be a level playing field, the traditional leader maintains their traditional leadership as long as that is something that is effectively leveraged by the software.
Otherwise, less-naturally-outperforming leadership may prevail once software comes on the scene, and it could very well be impossible for the previously-leading professional to compare with a peer who is also capable of writing the software themselves. Especially when there is good commercial or open-source software already. That way the domain expert having the programming ability doesn't have to spend time programming, but the insight into procuring software and creating workflows can't be matched after a certain point. Just because they actually are capable of programming it themselves if they really had to.
So true, but not everybody runs a company like it was a business :\
You may have to turn over every rock, but you just might find some bureaucracy "occasionally".
If your job is to manage X cases which have traditionally been done without a computer, you have the greatest advantage if you can outperform your peers when they don't have a computer either.
If X case management software is then adopted, there will once again be a level playing field, the traditional leader maintains their traditional leadership as long as that is something that is effectively leveraged by the software.
Otherwise, less-naturally-outperforming leadership may prevail once software comes on the scene, and it could very well be impossible for the previously-leading professional to compare with a peer who is also capable of writing the software themselves. Especially when there is good commercial or open-source software already. That way the domain expert having the programming ability doesn't have to spend time programming, but the insight into procuring software and creating workflows can't be matched after a certain point. Just because they actually are capable of programming it themselves if they really had to.
> Excel specifically is an example of "they just don't know any better", just like the everything-is-a-nail example (where Excel is the hammer and every problem looks like a spreadsheet). ... It's not that the sending and receiving didn't work at all, or that the software or the people are bad, it's just a really shitty "solution" that shouldn't be glorified and be seen as the failure to educate that it is.
This is an elitist software engineer's take.
People building on Excel isn't a result of failure to educate, it's humans doing what humans do best—automating their own workload. 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.
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". That's not going to happen, and it's frankly not something we should want to happen.
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. 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. 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.
This is an elitist software engineer's take.
People building on Excel isn't a result of failure to educate, it's humans doing what humans do best—automating their own workload. 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.
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". That's not going to happen, and it's frankly not something we should want to happen.
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. 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. 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.
> This is an elitist software engineer's take.
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.
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.
>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.
Then your CFO calls up and says, 'I have a meeting in 30 minutes, can you tell me the total cost of pensions for people who work out of the Singapore office on sales admin' and the BI developer never pulled the measures through for that, because nobody asked for it before... so you export it to Excel, do an xlookup, a sumif and a filter and keep your job...or put a request into IT to have it added, wait 3 weeks, and get fired.
In the real world there are measures repeated week after week, and there are many more ad-hoc requests. Your mental model of the information required to run a business is way off.
Then your CFO calls up and says, 'I have a meeting in 30 minutes, can you tell me the total cost of pensions for people who work out of the Singapore office on sales admin' and the BI developer never pulled the measures through for that, because nobody asked for it before... so you export it to Excel, do an xlookup, a sumif and a filter and keep your job...or put a request into IT to have it added, wait 3 weeks, and get fired.
In the real world there are measures repeated week after week, and there are many more ad-hoc requests. Your mental model of the information required to run a business is way off.
Exactly. When a process is important enough and repeated often enough, it will move into a more formal system. But most of the time spent running a business is at the fringes of what has been automated and formalized, and this isn't an accident—the automated processes are there precisely because they reduce or eliminate the human time. That means most of the humans (outside of front-line customer support or similar) tend to be working on stuff that is substantially less well-defined than what OP is imagining.
Which again gets to my point about the weird perspective on business that we have as software developers. We're called in exclusively to work on those parts of the business that are deemed sufficiently repetitive to be worth automating. That dramatically skews our perception of what running the business should look like.
Which again gets to my point about the weird perspective on business that we have as software developers. We're called in exclusively to work on those parts of the business that are deemed sufficiently repetitive to be worth automating. That dramatically skews our perception of what running the business should look like.
That's great, but has little to do with the 'excel is my hammer, therefore everything is an excel-shaped nail' problem.
Sure, like I wrote (twice already), you might need to have some malleable rows in front of you on your local workstation for some ephemeral work. But the actual workflow happens in the ERP system. Or the CRM. Or the PIM system. Or in Tableau. Or Databricks. And my beef is with people who think their personal flavour of alternate software should bypass that, even when they have been explicitly told not to. When someone needs to stream the truth (data-wise), that comes out of those systems, not some kludgy sheet on someone's network share. Those are the rules that we set up.
I don't understand why this is so difficult for everyone to understand (on HN of all places). These are general staff functions we practically have entire schools for, to make people work this way.
Sure, like I wrote (twice already), you might need to have some malleable rows in front of you on your local workstation for some ephemeral work. But the actual workflow happens in the ERP system. Or the CRM. Or the PIM system. Or in Tableau. Or Databricks. And my beef is with people who think their personal flavour of alternate software should bypass that, even when they have been explicitly told not to. When someone needs to stream the truth (data-wise), that comes out of those systems, not some kludgy sheet on someone's network share. Those are the rules that we set up.
I don't understand why this is so difficult for everyone to understand (on HN of all places). These are general staff functions we practically have entire schools for, to make people work this way.
I love that you mentioned PIM systems. I've worked with product information systems from small 3-man companies all the way to Fortune 500 companies, and without exception, their PIM systems have been total dogshit: slow, extremely unintuitive, limited in functionality and borderline unusable. When I need a list of product names, barcodes, weight and dimensions, nothing beats a simple Excel table that can be quickly transformed into whatever format I need at the moment. With the intensity of a thousand suns, I hate the "workflows" of having to create an account, sign in, browse products, put them into a cart, submit an order, and then wait for an email with a download link to some non-standard XML dump or broken CSV that their multi-million dollar PIM system produces. These systems have wasted entire lifetimes worth of their users' time. When it comes to sharing product information, nothing beats the ease of use and flexibility of a plain Excel table.
Our live PIM database is over 2TB, we're not going to copy that to excel. On top of that, we're also not going to have everyone do a little bit of PIM here and there, we stream 80 to 90 PIM mutations per second across various systems. You get a PIM frontend with appropriate access and that's it. Technically, the only real PIM work the teams do is corrections, there is practically no manual entry.
Luckily for us, we put request-response time in the requirements documents, so our PIM users get sub-50ms responses for everything.
As for sharing data, our manufacturers and subcontractors use APIs (with the exception of some wanting JSON uploads via SFTP), most of them stream directly into their PIM or ERP (yes, some don't have dedicated PIM systems and just use their ERP for that).
Even if we could have the data flow through individual workstations, we'd still not do that as we don't want to legal and repetitional risk associated with that, especially since it is completely avoidable.
As written in a different reply, sometimes people want to do some local fiddling around and they will export some data. But that data is considered expired, and not part of the normal data flow. Which was my point: spreadsheets are never part of the main loop. And anyone who wants to build a system where it is, is not working for us.
I do notice a trend here, lots of people having bad systems (slow PIM, outdated ERP, missing CRM), which is probably something that should be fixed, rather than taking the shadow route. Escaping to a spreadsheet is just that: escaping.
Luckily for us, we put request-response time in the requirements documents, so our PIM users get sub-50ms responses for everything.
As for sharing data, our manufacturers and subcontractors use APIs (with the exception of some wanting JSON uploads via SFTP), most of them stream directly into their PIM or ERP (yes, some don't have dedicated PIM systems and just use their ERP for that).
Even if we could have the data flow through individual workstations, we'd still not do that as we don't want to legal and repetitional risk associated with that, especially since it is completely avoidable.
As written in a different reply, sometimes people want to do some local fiddling around and they will export some data. But that data is considered expired, and not part of the normal data flow. Which was my point: spreadsheets are never part of the main loop. And anyone who wants to build a system where it is, is not working for us.
I do notice a trend here, lots of people having bad systems (slow PIM, outdated ERP, missing CRM), which is probably something that should be fixed, rather than taking the shadow route. Escaping to a spreadsheet is just that: escaping.
> Our live PIM database is over 2TB, we're not going to copy that to excel.
And you wouldn't need to, you would extract a much smaller subset to Excel and enjoy a superior user interface further analysing that
And you wouldn't need to, you would extract a much smaller subset to Excel and enjoy a superior user interface further analysing that
Our PIM team disagrees with that take. They enjoy the PIM interface and Excel doesn't come close to the data hierarchy and relationships our systems provide. And that includes reporting, vendor exchange and internal integrations.
But perhaps you're missing the point here (like plenty of others): it is not about handling a few offline rows, it's about re-inventing established systems that have proven their value and risk mitigations. We don't want someone to setup a collection files to build a homebrew PIM or ERP or CRM because they feel like it, disconnecting themselves from the organisation and teams they work with. In most cases, single player data silos are bad.
But perhaps you're missing the point here (like plenty of others): it is not about handling a few offline rows, it's about re-inventing established systems that have proven their value and risk mitigations. We don't want someone to setup a collection files to build a homebrew PIM or ERP or CRM because they feel like it, disconnecting themselves from the organisation and teams they work with. In most cases, single player data silos are bad.
Sure, agreeing would be a fireable offence "And anyone who wants to build a system where it is, is not working for us."
But the non-PIM teams agree, and they are a few orders of magnitude bigger and more important.
But the non-PIM teams agree, and they are a few orders of magnitude bigger and more important.
In the real world (which is where my example comes from) the CFO expects it in Tableau, all day, every day and isn't going to waste time on the phone with some random people who were assigned to put it in tableau. Perhaps you don't like this example, but that doesn't make it less real.
Ok. My real world counterpoint. I work for a CFO at a multinational. A really big one. I have been the finance lead at a multinational myself, a smaller one.
Our business changes so rapidly that we are forever adding business units, acquiring, divesting, resizing. The ERP people are years behind us all of the time.
What should we do in the mean time with our new group of companies we just acquired? Wait for the IT people?
Our business changes so rapidly that we are forever adding business units, acquiring, divesting, resizing. The ERP people are years behind us all of the time.
What should we do in the mean time with our new group of companies we just acquired? Wait for the IT people?
If your ERP can't keep up, then that is an ERP-shaped problem. Escalate with the CFO and CTO since the latter probably signed the responsibility/ownership (albeit probably indirectly) for delivery. In the mean time (since the real world is imperfect) you would of course rather kludge it than do nothing. But you would probably not rebuild the entire ERP in excel, forever, which is what I will fight against.
We don't have that problem, our ERP team can keep up. Perhaps that is because our rate of acquiring and divesting is maybe 2 or 3 cases per year. We are only active in a couple of countries per BU in the cases I write about, so that makes it easier as well.
On the other hand, if the ERP team isn't capable of producing the rate of change needed to support the business requirements, I really hope that you get that sorted since that is practically the entire reason an ERP team exists.
We do deploy changes (technical changes) about 200 times each day, of which the teams dealing directly with business workflows do about 60 (including some stock, pricing and WSSI teams). It's not a lot, but it allows us to have nearly no lag time between business needs and implementation delivery. It did take a while to get to that rate, and a 2-week feature freeze one time to shift all processes to a model that allows for this change rate. But it works well for us. (and reporting, visualisation, ETL, and ML are all done without spreadsheets for about 3 years now)
As for why we did that (in case that was a question you'd be asking since it is obviously not a change that costs nothing): we no longer wanted to accept the risk of doing it the old way, we also didn't want to have as much onboarding friction due to having many diverse sub-workflows inside teams, because even if you did learn about what someone DIY'ed in your local team, you will still run into the same problem ad-hoc when dealing with other teams, usually at the worst possible time. Same goes for off-boarding, we don't want to spend months trying to figure out what custom stuff someone put in place, especially since you get non-engineering solutions to engineering problems (the excel shaped one) but also engineering solutions to non-engineering problems (the python notebook one). We want our people to be able to spend as much of their time on the actual work instead of side quests that don't add the value we are looking for. It doesn't mean exploration or experiments are banned, but it does mean we want to facilitate as much as we can so you don't have to do anything extra by default.
We don't have that problem, our ERP team can keep up. Perhaps that is because our rate of acquiring and divesting is maybe 2 or 3 cases per year. We are only active in a couple of countries per BU in the cases I write about, so that makes it easier as well.
On the other hand, if the ERP team isn't capable of producing the rate of change needed to support the business requirements, I really hope that you get that sorted since that is practically the entire reason an ERP team exists.
We do deploy changes (technical changes) about 200 times each day, of which the teams dealing directly with business workflows do about 60 (including some stock, pricing and WSSI teams). It's not a lot, but it allows us to have nearly no lag time between business needs and implementation delivery. It did take a while to get to that rate, and a 2-week feature freeze one time to shift all processes to a model that allows for this change rate. But it works well for us. (and reporting, visualisation, ETL, and ML are all done without spreadsheets for about 3 years now)
As for why we did that (in case that was a question you'd be asking since it is obviously not a change that costs nothing): we no longer wanted to accept the risk of doing it the old way, we also didn't want to have as much onboarding friction due to having many diverse sub-workflows inside teams, because even if you did learn about what someone DIY'ed in your local team, you will still run into the same problem ad-hoc when dealing with other teams, usually at the worst possible time. Same goes for off-boarding, we don't want to spend months trying to figure out what custom stuff someone put in place, especially since you get non-engineering solutions to engineering problems (the excel shaped one) but also engineering solutions to non-engineering problems (the python notebook one). We want our people to be able to spend as much of their time on the actual work instead of side quests that don't add the value we are looking for. It doesn't mean exploration or experiments are banned, but it does mean we want to facilitate as much as we can so you don't have to do anything extra by default.
See my other comment, we have over 1000 factories in many countries. 23 different ERPs in my division alone apparently. They are constantly trying to standardise, but acquisitions happen faster than factory ERP implementations. When you acquire a group that isn't standardised itself you have even more systems. That is one reason why complex groups use consolidation systems.
I'm guessing your company is somewhat more homogeneous than us conglomerates?
Edit: no it is not an ERP problem. It is a people problem. The team simply can't scope out the new factories quickly enough before the business changes something. Often the newly acquired factory has a different costing method for instance, and lots of data has to be collected before they can go on the master ERP. This may involve, for instance, timing every products build, collating and verifying it (in Excel probably), before the implementation can progress. This can take months. Especially when.... three main priority is selling stuff, rather than having neat BI
I'm guessing your company is somewhat more homogeneous than us conglomerates?
Edit: no it is not an ERP problem. It is a people problem. The team simply can't scope out the new factories quickly enough before the business changes something. Often the newly acquired factory has a different costing method for instance, and lots of data has to be collected before they can go on the master ERP. This may involve, for instance, timing every products build, collating and verifying it (in Excel probably), before the implementation can progress. This can take months. Especially when.... three main priority is selling stuff, rather than having neat BI
At the end of the day, everything is a people problem. I tried checking the other comment but I couldn't find it (I thought I replied to it actually but it seems it was a different one about non-integrated ERPs).
We are not a conglomerate of 10+ nation size (slightly below that; also not the best measure but trying to toe the line with sharing but not naming gets harder with detail) but I suppose since we had to pivot from financial services to CPG a while ago and B2C retail in our segment at that time really demanded extremely low lag&lead-times for user changes and onboarding of products and services (well, VAS.. but who's counting), we engineered our way out of it, including logistics, SCADA, web, mobile apps, people-onboarding and M&A onboarding.
Having neat BI is more a side-effect than a primary goal. That goal came much later since it was the last remaining driver of shadow processes as it lead to many opportunities of bad engineering, even if it was seen as valuable in the short term (it never was worth it in the long run). It wasn't even about spreadsheets (or excel specifically), it became a real-time streaming issue where you couldn't have a fully manual process in the loop any more and we couldn't hire extra people fast enough to keep the existing processes running at the rate we needed. We don't have data entry positions anymore for the same reason; it's not that we don't receive new data, it's just that we had all B2B contacts agree that they will not send or receive files between humans if it's regarding an automated streaming process.
Having our data architecture being based on real time streaming (and some periodic sanity checks and shadow reconciliation as that is mandated by some record keeping laws) means we beat practically everyone in the same market segment on speed and delivery.
But perhaps this ties in to us being more homogeneous than some other conglomerates. We're not doing more than 5 countries and don't have our acquisitions result in extra divisions as we tend to aim for competitors in the segments we want to grow in (we want the data, the people and the customers, not the systems). This means that the people that operate the business (be it the business processes or the actual product processes) don't really get 'extra' software as a result.
We are not a conglomerate of 10+ nation size (slightly below that; also not the best measure but trying to toe the line with sharing but not naming gets harder with detail) but I suppose since we had to pivot from financial services to CPG a while ago and B2C retail in our segment at that time really demanded extremely low lag&lead-times for user changes and onboarding of products and services (well, VAS.. but who's counting), we engineered our way out of it, including logistics, SCADA, web, mobile apps, people-onboarding and M&A onboarding.
Having neat BI is more a side-effect than a primary goal. That goal came much later since it was the last remaining driver of shadow processes as it lead to many opportunities of bad engineering, even if it was seen as valuable in the short term (it never was worth it in the long run). It wasn't even about spreadsheets (or excel specifically), it became a real-time streaming issue where you couldn't have a fully manual process in the loop any more and we couldn't hire extra people fast enough to keep the existing processes running at the rate we needed. We don't have data entry positions anymore for the same reason; it's not that we don't receive new data, it's just that we had all B2B contacts agree that they will not send or receive files between humans if it's regarding an automated streaming process.
Having our data architecture being based on real time streaming (and some periodic sanity checks and shadow reconciliation as that is mandated by some record keeping laws) means we beat practically everyone in the same market segment on speed and delivery.
But perhaps this ties in to us being more homogeneous than some other conglomerates. We're not doing more than 5 countries and don't have our acquisitions result in extra divisions as we tend to aim for competitors in the segments we want to grow in (we want the data, the people and the customers, not the systems). This means that the people that operate the business (be it the business processes or the actual product processes) don't really get 'extra' software as a result.
[deleted]
> 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.
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
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
[deleted]
I would temper your hot take.
Nothing you described is a feature specific to Excel from what I can tell, and using Excel in front of an ERP is most likely an anti-pattern as the ERP is meant to handle reporting and authorization in a centralized way.
Ha ha ha
The power of ERP is that it is so rigid and repeatable. Which is great for all the things that stay the same. My country just introduced a law on reporting payment performance to suppliers. My US ERP provider didn't think of that 5 years ago...so we did it in Excel. Say we are in 50 countries (we are in more) each with their own changing requirements... think the ERP could keep up?
But not all of the places in my country are on the same ERP. Many of the foreign places are not (the joys of acquisition!) yet. What do we do in the mean time?
The power of ERP is that it is so rigid and repeatable. Which is great for all the things that stay the same. My country just introduced a law on reporting payment performance to suppliers. My US ERP provider didn't think of that 5 years ago...so we did it in Excel. Say we are in 50 countries (we are in more) each with their own changing requirements... think the ERP could keep up?
But not all of the places in my country are on the same ERP. Many of the foreign places are not (the joys of acquisition!) yet. What do we do in the mean time?
Nearly everyone who knows how to use a computer knows how to use Excel to some extent. That is a feature of Excel that pretty much no other software solution can bring to the table.
I would contend that any user that can use Excel could pick up e.g. Google sheets instantly, especially in an audit capability where you want to scan the data (and view a couple formulae) rather than craft it from scratch.
Yeah. But then all your data lands at Google and now you’re at their mercy. I like my Excel offline thank you.
I now I am probably part of a minority but I am totally lost with excel (and libreoffice calc).
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.
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.
Just because everyone uses it for that purpose doesn't automatically make it the best tool or the right tool for the job. In the beginning when it was a spreadsheet that meant to do spreadsheets stuff it was fine because it fulfilled that purpose. The problem is users who failed to learn any other tool continued to use it for things it was not adapted to do. Microsoft being a company that likes money and it simply being a piece of software means that they could adapt it to do all kinds of things that are better fulfilled by a different tool. Just because they adapted it to make it a database and a spreadsheet hybrid thing doesn't mean it was also the right thing to do. It was the thing to do that made them money and have them capture market share.
Overall it allowed a segment of the population to continue to remain ignorant of all of the other tools available that were better suited to their needs. It also allowed them to remain ignorant for all the methods to relate data between multiple tools that are adapted to do their jobs better.
So ultimately the only people this has really benefited is Microsoft. the users believe that they're getting a benefit but it is actually a net negative because it discourages growth it discourages learning it discourages understanding the best tool for the job outcomes.
It literally is the axiom of if the only tool you have is a hammer every problem looks like a nail personified to the maximum extent possible.
Overall it allowed a segment of the population to continue to remain ignorant of all of the other tools available that were better suited to their needs. It also allowed them to remain ignorant for all the methods to relate data between multiple tools that are adapted to do their jobs better.
So ultimately the only people this has really benefited is Microsoft. the users believe that they're getting a benefit but it is actually a net negative because it discourages growth it discourages learning it discourages understanding the best tool for the job outcomes.
It literally is the axiom of if the only tool you have is a hammer every problem looks like a nail personified to the maximum extent possible.
> Just because everyone uses it for that purpose doesn't automatically make it the best tool or the right tool for the job.
On the contrary, in many domains in life the right tool for the job is almost always going to be the one that everyone is already using. It's usually not the most satisfying tool or the most elegant, and its use will usually make perfectionists scream, but if you're actually interested in getting anything done you'll default to using the tool that the human beings in the system are already comfortable with unless it would be completely impossible to do so.
As another example: the NEMA connector is objectively bad compared to modern alternatives, but it's not going anywhere. The benefits of standardization usually outweigh the benefits of optimization, and you usually don't benefit from being the first to move to the "better" solution.
(I realize that last part is difficult to swallow for a forum that's focused on startups trying to disrupt the existing, standardized tech.)
On the contrary, in many domains in life the right tool for the job is almost always going to be the one that everyone is already using. It's usually not the most satisfying tool or the most elegant, and its use will usually make perfectionists scream, but if you're actually interested in getting anything done you'll default to using the tool that the human beings in the system are already comfortable with unless it would be completely impossible to do so.
As another example: the NEMA connector is objectively bad compared to modern alternatives, but it's not going anywhere. The benefits of standardization usually outweigh the benefits of optimization, and you usually don't benefit from being the first to move to the "better" solution.
(I realize that last part is difficult to swallow for a forum that's focused on startups trying to disrupt the existing, standardized tech.)
I would disagree that in many domains that this makes this the right choice. The domain scope that it makes "already known" the default right choice is generally when you're choosing short-term cost optimization over all other options. This is what Excel has fallen into. It has not produced a better outcomes it has arguably produced worse outcomes. Because the idea of bloat is a real thing.
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.
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.
The problem is that most of the time what software engineers say is "better" just isn't.
Suddenly instead of being comfortable using the tool themselves, they have to request engineer time to update the UI. Instead of being able to write whatever weird excel formulas they have they maybe now need to learn SQL. Maybe they "should" but that is kind of besides the point
Suddenly instead of being comfortable using the tool themselves, they have to request engineer time to update the UI. Instead of being able to write whatever weird excel formulas they have they maybe now need to learn SQL. Maybe they "should" but that is kind of besides the point
gjsman-1000(1)
Excel is probably the most useful application ever made. Pretty much every professional services implementation and technical account management engagement is done via excel.
For me, I've used it for budgets, to-do lists, etl, reporting, financials. Its data handling utility is pretty much unmatched. It's super easy at this point to see anything with it.
It's well worth any price for sure. It's really the only reason I have a 365 subscription at this point. And like everyone else, I doubt I've used more than 2% of it.
For me, I've used it for budgets, to-do lists, etl, reporting, financials. Its data handling utility is pretty much unmatched. It's super easy at this point to see anything with it.
It's well worth any price for sure. It's really the only reason I have a 365 subscription at this point. And like everyone else, I doubt I've used more than 2% of it.
I have several extremely complex spreadsheets that have reached a breaking point because "the maximum number of fonts has been exceeded". There's like 8 fonts being used at most. The problem is, I don't have an alternative piece of software that can maintain the other very complicated formatting, let alone import it. And it now starts to revert formatting randomly throughout the spreadsheets. It's a widely known problem with no solution I can find to date.
Google Sheets is great, but I'm probably one of the very few people who thinks we need a more robust and feature rich spreadsheet software, if only to compel Microsoft to strengthen their own.
Google Sheets is great, but I'm probably one of the very few people who thinks we need a more robust and feature rich spreadsheet software, if only to compel Microsoft to strengthen their own.
I must admit, of all the stories I’ve heard about Excel spreadsheets being “this one goes up to eleven” in their complexity, “too many fonts” is a new one.
Perhaps you could use an alternative differentiator for your data presentation?
I’m morbidly curious to hear more about this scenario.
Perhaps you could use an alternative differentiator for your data presentation?
I’m morbidly curious to hear more about this scenario.
To add my own anecdote, I've needed to use a lot of spreadsheets the last couple weeks and quickly became annoyed that different cells could have different fonts (which would sometimes happen when I was pasting in data). Of course I quickly learned to just paste in everything unformatted, but I thought to myself "why would anyone want to set fonts per cell?" I guess I just don't get out enough.
The "paste with styles" default is one of the worst things ever IMO. It's almost never what I want.
I hate it so much... some programs are even worse, they don't take ctrl shift v to get rid of the garbage. I've made it a habit to first paste stuff in a text editor, copy it again, and then paste it into programs like outlook so the formatting won't be all messed up...
Still don't know of a single case where the "feature" was useful.
Still don't know of a single case where the "feature" was useful.
Try the "Paste as plain text" tool in PowerToys - https://learn.microsoft.com/en-us/windows/powertoys/advanced....
PowerPoint
Paste with source formatting or theme, I can't recall the exact name right now, rules. It means being able to mooch slides from any file and use them with no real fuss.
An alternative is to turn the slide into a bitmap.
Paste with source formatting or theme, I can't recall the exact name right now, rules. It means being able to mooch slides from any file and use them with no real fuss.
An alternative is to turn the slide into a bitmap.
I get that there are a few cases where it's useful. Make those require "ALT-SHIFT' or whatever. Make normal paste insert just the text.
Yep. I agree! Sorry, it just popped out.
Your primary point is solid. Seconded.
Your primary point is solid. Seconded.
I think you are in good company. I’ve used excel extensively, and I’ve never even conceived of that number of fonts specifically being needed. Let alone breaking excel on fonts.
I’ve wondered about it for years; why is the ‘paste’ command not ‘paste without style’ by default? A system level option to change this would be a vast improvement.
I’ve seen all sorts of gross workarounds. The URL bar is my go to these days, mainly because that works on mobile.
I’ve seen all sorts of gross workarounds. The URL bar is my go to these days, mainly because that works on mobile.
Not parent, but in my spreadsheets fonts map to certainty ranges.
Serifs in increasing somberness for the most concrete numbers, sans for everyday estimates, and papyrus whenever I just toss random numbers in.
Serifs in increasing somberness for the most concrete numbers, sans for everyday estimates, and papyrus whenever I just toss random numbers in.
Could a human - in your scenario - differentiate the meaning between more than 8 fonts though?
When you've slowly built up a UI for your own purposes— whether the accretions are font faces or keybindings or context menu items— definitely! Picture a spreadsheet/convention that has evolved over the course of 6 years, seeing continuous use throughout that time.
As someone with color discrimination problems and contrast difficulties, I would so much prefer font/style coding over color coding. Sounds great!
As someone with color discrimination problems and contrast difficulties, I would so much prefer font/style coding over color coding. Sounds great!
Now, this is extremely interesting!
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.
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.
[deleted]
> It's a widely known problem with no solution I can find to date.
I can think of a solution: don’t use 9 different fonts.
You have cell background and text foreground color, font size, bold, underline, italics, strike through, cell border styles, conditional formatting, etc. There are plenty of formatting tools in Excel.
What are you not able to accomplish with those that you can accomplish with 9 font faces?
I can think of a solution: don’t use 9 different fonts.
You have cell background and text foreground color, font size, bold, underline, italics, strike through, cell border styles, conditional formatting, etc. There are plenty of formatting tools in Excel.
What are you not able to accomplish with those that you can accomplish with 9 font faces?
>don’t use 9 different fonts. You have ... font size, bold, underline, italics
so, what you are calling "fonts" (Arial, Times) are actually called "typefaces"
every pointsize in a typeface is a new font, and bold and italics the same.
so, we don't know if Excel is making the same common/casual error you are, but if their error message is "technically correct (the best kind of correct)", then italics and bold in each pointsize are all separate fonts, and that's what he might have too many of.
so, what you are calling "fonts" (Arial, Times) are actually called "typefaces"
every pointsize in a typeface is a new font, and bold and italics the same.
so, we don't know if Excel is making the same common/casual error you are, but if their error message is "technically correct (the best kind of correct)", then italics and bold in each pointsize are all separate fonts, and that's what he might have too many of.
you can be very pedantic about it, but Excel has no problem with 8+ variations of font size, color, and formatting, and everyone outside of typeface designers and newspaper men references typefaces as "the font".
Excel also has no problem with more than a dozen typefaces, with one size/style of each (I just tested it.)
The error message is probably using “fonts” in the technically correct sense for combinations of typeface, size, and style, while the user experiencing the error is probably confused and reporting that they are only using 8 “fonts” using the term to mean typefaces (which is how Excel itself uses the term in the UI, with the typeface selector using the label “Fonts”.) But if you are using 8 typefaces, using multiple sizes and styles of each, you can easily be using over 100 actual fonts.
The error message is probably using “fonts” in the technically correct sense for combinations of typeface, size, and style, while the user experiencing the error is probably confused and reporting that they are only using 8 “fonts” using the term to mean typefaces (which is how Excel itself uses the term in the UI, with the typeface selector using the label “Fonts”.) But if you are using 8 typefaces, using multiple sizes and styles of each, you can easily be using over 100 actual fonts.
you can't attempt to decipher the error message without knowing the distinctions, and listen to you getting all pedantic with the history of newspapermen etc. eyeroll.gif
> so, what you are calling “fonts” (Arial, Times) are actually called “typefaces”
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…)
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…)
the reason font menus are called font menus and not typeface menus dates back to when computers used raster fonts and had limited memory. You didn't load typefaces, you loaded the typeface/size/styles that you needed and had memory for, literally the fonts. Since that's the language people learned, that's what's in the UI
Try it with more memory and/or larger swapfile space on your drive.
It might be OK until 8 specialty fonts need to be reproduced beyond a certain number of cells. If more memory was all it takes to fix, that would be good to know.
It might be OK until 8 specialty fonts need to be reproduced beyond a certain number of cells. If more memory was all it takes to fix, that would be good to know.
And there I was getting bothered about the limits of the xlcall c api.
Running 32-bit Excel mitigates quite a few of the limits. Sadly, I haven't managed to get WoW64 DLLs to load in 64-bit Excel: that would eliminate the majority of the issues, but it's tricky to set that up in the first place without the ability to store 64-bit return values (e.g. handles).
I can't imagine the use case for having more than 1 font in a spreadsheet. Please elaborate. I'm pretty sure Excel is the wrong tool for whatever job you are throwing at it.
Maybe a title, and perhaps some callout cells? but more than 8? I'm stretching to find a use case requiring 3 or 4.
I feel like this is a pretty important thing for the technically minded to get their heads around.
Doesn't the fact that you can't imagine a single reason why youd want multiple fonts on a spreadsheet alarm you?
Doesn't the fact that you can't imagine a single reason why youd want multiple fonts on a spreadsheet alarm you?
Excel is for spreadsheets, 9+ fonts is not really a common use case for a spreadsheet. It sounds like OP is trying to do graphic design in Excel, but we'll probably never find out.
I had a friend who used Excel to render blueprints for the dream house she was designing. As an architecture student, I was both impressed and horrified!
> I'm pretty sure Excel is the wrong tool for whatever job you are throwing at it.
Thanks, you completed my bingo card.
Thanks, you completed my bingo card.
You're pretty sure it's the wrong tool, but you can't imagine a use case for a fairly basic feature of said tool?
Why do I now doubt your assertion?
Why do I now doubt your assertion?
[flagged]
Sure, nine is a lot,
but your comment says "more than 1 font". Without arguing the semantics of what you meant by "font", hopefully using different font sizes and emphasis (bold/italics) do make sense to you. If those make sense, then using a different font entirely shouldn't be too complicated to see as a feature that an Excel user who's not using it for graphics design reasonably want.
Legibility is an important consideration, and with Excel, the size of sheets tend to grow until there are too many columns. So now you have the normal regular size font and you use a different font that's more legible at small sizes, especially when rotated 90.
There have been umpteen attempts to replace Excel. User interviews to understand how customers actually use the tool are important. Having the hubris to say customers are doing it wrong without even bothering to understand their use case is the first step to failing at replacing Excel.
Don't get me wrong, I cringe every time I fire up a spreadsheet and it grows past a reasonable size or length of use, or any number of shortcomings. Sometimes I even switch tools or write my own when that happens but lately I find Airtable's a pretty good replacement for most human (aka not finance) use of spreadsheets.
Legibility is an important consideration, and with Excel, the size of sheets tend to grow until there are too many columns. So now you have the normal regular size font and you use a different font that's more legible at small sizes, especially when rotated 90.
There have been umpteen attempts to replace Excel. User interviews to understand how customers actually use the tool are important. Having the hubris to say customers are doing it wrong without even bothering to understand their use case is the first step to failing at replacing Excel.
Don't get me wrong, I cringe every time I fire up a spreadsheet and it grows past a reasonable size or length of use, or any number of shortcomings. Sometimes I even switch tools or write my own when that happens but lately I find Airtable's a pretty good replacement for most human (aka not finance) use of spreadsheets.
[flagged]
This is a very basic article compared to the conversation here.
Excel is incredible for being so simple to use for even the most basic tasks (Baby names v2.xlsx) to the much more complex data analysis.
As someone who uses Excel for 75% of my workweek, I wouldn't trade it for a 10% comp increase, because doing so would increase my workload at least 25%.
I recently tried moving to Google Sheets and it was unbelievable how slow computationally heavy queries would take compared to Excel, or how painful the lack of shortcuts is.
Even things like how cells are frozen (if you're on B2, are you freezing the first row, or the first and second row?) just feels wrong.
So, is it product quality or deeply built habits? Probably a mix of both. Yes, I grew up with it too, and I wouldn't have it any other way.
Excel is incredible for being so simple to use for even the most basic tasks (Baby names v2.xlsx) to the much more complex data analysis.
As someone who uses Excel for 75% of my workweek, I wouldn't trade it for a 10% comp increase, because doing so would increase my workload at least 25%.
I recently tried moving to Google Sheets and it was unbelievable how slow computationally heavy queries would take compared to Excel, or how painful the lack of shortcuts is.
Even things like how cells are frozen (if you're on B2, are you freezing the first row, or the first and second row?) just feels wrong.
So, is it product quality or deeply built habits? Probably a mix of both. Yes, I grew up with it too, and I wouldn't have it any other way.
> Even things like how cells are frozen (if you're on B2, are you freezing the first row, or the first and second row?) just feels wrong.
FWIW one my frustrations with Excel is how it does freezing of rows. I find Google's appraoch more intuitive. But the issues on computation I agree with (see my other comment on this post).
FWIW one my frustrations with Excel is how it does freezing of rows. I find Google's appraoch more intuitive. But the issues on computation I agree with (see my other comment on this post).
As a point of data, I also find how Google Sheets handles frozen rows/columns more intuitive.
I have my personal weekly budget spreadsheet open on my laptop at all times. I balance my checking account almost daily to know where all the money is going. I did pay for Monarch to see if it would be better and although it’s nice, Excel is still just better.
One of my favorite tabs is taking a high interest loan or credit card and increasing the payment amounts (even a little) to reduce the overall impact of the interest rate, something a lot of people don’t understand.
You will pry Excel from my cold dead hands.
One of my favorite tabs is taking a high interest loan or credit card and increasing the payment amounts (even a little) to reduce the overall impact of the interest rate, something a lot of people don’t understand.
You will pry Excel from my cold dead hands.
While I understand the power of Excel for specific calculations like your loan payment analysis, I struggle with modeling "continuous" data like monthly budgets and yearly reviews. Coming from a database background, I know how to model recurring financial data with tables and relationships, but I'm less clear on Excel best practices for this.
How do you structure your spreadsheet to handle: 1. Monthly recurring budgets/allowances 2. Year-over-year analysis 3. Category management 4. Historical tracking
Do you maintain separate sheets/tabs for each time period? Use pivot tables?
How do you structure your spreadsheet to handle: 1. Monthly recurring budgets/allowances 2. Year-over-year analysis 3. Category management 4. Historical tracking
Do you maintain separate sheets/tabs for each time period? Use pivot tables?
I suspect that your database background is causing you to think too formally about how people structure Excel data. For the vast majority, they’re not normalizing data, running queries on sheets, etc. I can easily see this as one tab per account, then pulling in specific cells on other tabs for summaries and other analysis.
Isn’t this exactly the sort of thing spreadsheets are good for? I feel like I must be misunderstanding what you’re doing.
It is nice to have a schema. Once you use schemas, it's hard to think otherwise. It feels gross.
Maybe if you have millions of rows you might have trouble with excel. Other than that, from a data storage perspective an Excel is just a database that’s human readable.
Not really. It generally won't have a schema. You generally can't write queries against it.
> You generally can't write queries against it.
Yes you can, there are a lot of different ways of doing it depending on what type of data you have and how you structured it.
Yes you can, there are a lot of different ways of doing it depending on what type of data you have and how you structured it.
Once you go down the relational path, it's really hard to get out of it (and I don't even think you should, I think you are right).
There are many ways to skin a cat, but my advice how to try it an excel way (assuming a db backgound) would be..
try dumber things, sounds stupid but you dont need rules and structure, just data :)
denormalise a more often to break down the problem, the data and problem are your goal not structure (as much as db).
Yes period per tab type of thing is quite common, as at some point you want to close the period and never change it.
Lean into the non-standardisation to handle the real world. E.g for most of your budget its one line per item per month but this one are flexes with headcount so that has its own page, and tax is balnced in month x so ill just over type all the formulae there when the real numbers come in.
Also if the model is complex try naming fields and showing the formula in a cell next to it to remind you how its calculated (if not ready using it check out "format as table" to do this for tabular data)
And yes pivot the crap out of everything.
There is also "add to model" which gives you powerbi type modelling in excel which can also be handy and fast.
Not extensive list, and for lots of things db is better when you know how to use it.. but those are some of the "i get it" scenarios for me
try dumber things, sounds stupid but you dont need rules and structure, just data :)
denormalise a more often to break down the problem, the data and problem are your goal not structure (as much as db).
Yes period per tab type of thing is quite common, as at some point you want to close the period and never change it.
Lean into the non-standardisation to handle the real world. E.g for most of your budget its one line per item per month but this one are flexes with headcount so that has its own page, and tax is balnced in month x so ill just over type all the formulae there when the real numbers come in.
Also if the model is complex try naming fields and showing the formula in a cell next to it to remind you how its calculated (if not ready using it check out "format as table" to do this for tabular data)
And yes pivot the crap out of everything.
There is also "add to model" which gives you powerbi type modelling in excel which can also be handy and fast.
Not extensive list, and for lots of things db is better when you know how to use it.. but those are some of the "i get it" scenarios for me
What does Excel do here that Google Sheets doesn’t? I don’t always carry my laptop with me, so local files are kind of annoying.
I’m not the commenter that you’re replying to but I always get a different “feel” when using a native application like Excel than a web app. I can type as fast as I can think, switching cells, typing values, invoking keyboard shortcuts, etc, and every keystroke is interpreted as I intended. It’s incredible what’s been achieved in modern web apps like Google Sheets, but I still feel like I need to slow down at times to watch what the app is up to - making sure the cell was selected in the UI before entering text or watching to be sure the browser didn’t intercept a shortcut, etc.
If any Excel alternative wants to make a dent in market share, they need an option for users to mimic all the main Excel shortcuts. Google Sheets is close so it's useable; however, trying to use something like Apple Numbers is like switching from querty to dvorak.
Robust macro capability (VBA>AppScript), more advanced data analysis/validation and charting, easy integration with SQL/PBI, a mature add-in market.
And less tangible: it just feels much faster. I don't have any data for this last claim, it's purely based on personal experience. Although, when I use web Excel, this edge goes away.
And I don't use local files at all with Excel. Everything is either in OneDrive or SharePoint, accessible through web or app on whatever platform.
And less tangible: it just feels much faster. I don't have any data for this last claim, it's purely based on personal experience. Although, when I use web Excel, this edge goes away.
And I don't use local files at all with Excel. Everything is either in OneDrive or SharePoint, accessible through web or app on whatever platform.
You can use Excel in the exact same way with Microsoft 365.
Last time I had to use it, Microsoft 365's web version was missing a ton of functionality, even more than Google Sheets is. If I need Excel I need Excel, if I can make do with a web version then I'm not going to use Microsoft's.
These days, I prefer google sheets for most things spreadsheet, but Excel is far and away more capable, and after a certain level of complexity, just unbelievably fast in comparison. Complex sheets in Google Sheets get bogged down very quickly, and the data-access support is weaker and handles errors very poorly.
If you do any serious financial planning for a startup or small business, Excel is vastly superior to Google Sheets. The multi sheet formulas can get very complicated and web based tools can’t perform as well as desktop software.
Where does the syntax differ between Google sheets and Excel that multisheet formulas are more complicated in Google sheets vs Excel?
It’s the required cpu cycles you’re not going to get in any browser based app.
Google Sheets doesnt have Solver in the consumer version for one.
In reference to your second statement though, I also dont always carry my laptop but it doesn't matter because my spreadhseets are in onedrive too, so I can close my laptop and open my phone and have the same spreadsheet with zero thought.
In reference to your second statement though, I also dont always carry my laptop but it doesn't matter because my spreadhseets are in onedrive too, so I can close my laptop and open my phone and have the same spreadsheet with zero thought.
What problem does Solver solve? Reading the overview, I don't really understand how it would be useful.
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://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.
The main use of the solver is for something that definitely cannot be done without programming vba macro. You use it to find the optimal value in a cell based on the result in a different cell. You have a cell that excels will solve, a cell with the objective and constraints.
For example, let's say you have a spreadsheet to calculate the capacity of a steel column based on its height and cross-section/material. If you wanted to run the calculation backward and find the height that will give you a very specific capacity, you could do it manually by playing with the height until you find it or you can let Excel do it for automatically with the solver.
For example, let's say you have a spreadsheet to calculate the capacity of a steel column based on its height and cross-section/material. If you wanted to run the calculation backward and find the height that will give you a very specific capacity, you could do it manually by playing with the height until you find it or you can let Excel do it for automatically with the solver.
> What does Excel do here that Google Sheets doesn’t?
Tables.
Tables.
Google Sheets has tables now
https://workspaceupdates.googleblog.com/2024/05/tables-in-go...
https://workspaceupdates.googleblog.com/2024/05/tables-in-go...
They seem much worse than Excel's though. Are structured references supported? Can the tables be moved without breaking references? It also seems to me that the filter views aren't implemented in the mobile apps yet, so you can end up with a PC-only document.
Cool. I have learned something new!
> One of my favorite tabs is taking a high interest loan or credit card and increasing the payment amounts (even a little) to reduce the overall impact of the interest rate, something a lot of people don’t understand.
Looks like I belong to those people that don't understand: What "payment amounts" are you increasing?
Looks like I belong to those people that don't understand: What "payment amounts" are you increasing?
Presumably they're talking about paying down more of the principle sooner, lowering the interest amounts.
Take any loan/credit and stretch it out until it’s paid off under the current parameters. You can calculate total interest paid.
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”.
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”.
There is the "debt is bad" viewpoint, where paying your loan earlier is seen as a good thing, which is a valid way to look at it, depending on your values.
However, what you described can also be done this way: invest the extra payment amount elsewhere and get interest/capital gains on it, which gives you the lower effective interest rate and the extra liquidity as well. Or in other words, the figures on the spreadsheet need to reflect the opportunity cost of the extra payment, or the lower total interest paid is a misleading mirage.
However, what you described can also be done this way: invest the extra payment amount elsewhere and get interest/capital gains on it, which gives you the lower effective interest rate and the extra liquidity as well. Or in other words, the figures on the spreadsheet need to reflect the opportunity cost of the extra payment, or the lower total interest paid is a misleading mirage.
There are definitely levels of sophistication in managing interest liabilities. If you have a mortgage at 3%, paying the principal early is wasting your extra monty. As you said, you can invest the extra and make 7% (hypothetical) and clearly that’s advantageous.
My example is for people struggling with credit cards and high interest loans that don’t have investment properties.
My example is for people struggling with credit cards and high interest loans that don’t have investment properties.
> I balance my checking account
Assuming that this relates to checks/cheques, are they going away in the US?
Assuming that this relates to checks/cheques, are they going away in the US?
“Balancing a checking account” in American vernacular is typically used to mean reconciling the transactions your bank has posted to the spend you’ve tracked.
This used to be more important when you wrote paper checks and received a monthly paper statement from your bank. Most people who “balance” their accounts today seem primarily concerned that they are adhering to their personal budget. But the term remains.
This used to be more important when you wrote paper checks and received a monthly paper statement from your bank. Most people who “balance” their accounts today seem primarily concerned that they are adhering to their personal budget. But the term remains.
This was my meaning. It’s all about adhering to a budget and seeing it going forward.
It's very uncommon to use them for any common expenses like groceries or gas. I use them for a quarterly HOA payment, yearly CPA tax preparation, petty government fines and fees, and donations to charity. Generally things that you mail a payment for and you want a record of the payment. Most of these I could do electronically but I don't really save any time doing so because of the friction of setting up the payment.
> Generally things that you mail a payment for
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.
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.
When I want to transfer currency units to entities which are not within range of any personal locomotion apparatus, I utilize a government service that transfers paper parcels anywhere in the country for a fixed rate. A few days later the receiver redeems the check for currency units deposited into their banking account.
I don't understand either, but I would be genuinely interested in what "mailing a payment" means in practice. Is it like sending a check by mail or some kind of paper bank transfer?
Sending a check via mail is infrequently done, but it happens. I just paid my annual property taxes that way. My options were:
* mailing a check
* paying via credit card over the phone for a hefty surcharge
* cash in person
In my case, I used my online banking to send the amount to the mailing address on the bill. In some cases - for large companies, typically - my bank can send the remittance electronically. In others, though, they fill out a paper check on my behalf and send it via the postal system. This service is fee free to me, or else I’d have sent the letter myself.
* mailing a check
* paying via credit card over the phone for a hefty surcharge
* cash in person
In my case, I used my online banking to send the amount to the mailing address on the bill. In some cases - for large companies, typically - my bank can send the remittance electronically. In others, though, they fill out a paper check on my behalf and send it via the postal system. This service is fee free to me, or else I’d have sent the letter myself.
You say ‘the cheque is in the mail’ when you intend to ignore an instruction whilst pretending to comply.
The European mind cannot comprehend how primitive American consumer banking is.
Many of us still write them semi-regularly although many are "written" by the bank. I admit that I keep my eye on my banking account online but otherwise don't pay a lot of attention day to day. Far larger amounts of cash are flowing through my credit cards than any individual direct payments.
Okay, here goes nothing. My small take on the Excel story.
The year was 1986, pre-spreadsheets. Writing up an undergrad physics experiment in 1986, I needed to do a hundred or so similar calculations and present the results in a table. Luckily, a computer science acquaintance wrote a small program to do this task for me. Thanks, Dan.
In 1989, before Excel, there was Lotus 1-2-3. Loved that spreadsheet software. My PhD task involved plotting lots of data points, including smoothing some of them. Doable with Lotus 1-2-3, probably not doable otherwise.
More recent times.
Spaghetti Excel. An engineering acquaintance told me his student summer job, at an aluminum refinery, was to check and simplify their Excel spreadsheets. Apparently they had numerous spreadsheets linked to each other. I assume the main purpose was inventory control. I know I didn't envy him his task.
"Please, not just Excel." I took a class of high school students to a uni chem lab and had a small argument with a chemistry tutor who insisted the students use Excel to plot their data. I wanted them to first do it by hand with graph paper. This would have given them a much better feel for their data.
"Rinse-and-repeat Excel". I was tutoring a construction guy trying to learn maths. His job as an assistant on a high-rise construction job involved putting lots of numbers into an Excel spreadsheet. The check for this was to repeat the process and see if he got an identical result. I thank G*d his boss made him do this.
And that's it. Helped other people to use Excel, but I'm thankful that I haven't had to spend my life inputting data into spreadsheets.
The year was 1986, pre-spreadsheets. Writing up an undergrad physics experiment in 1986, I needed to do a hundred or so similar calculations and present the results in a table. Luckily, a computer science acquaintance wrote a small program to do this task for me. Thanks, Dan.
In 1989, before Excel, there was Lotus 1-2-3. Loved that spreadsheet software. My PhD task involved plotting lots of data points, including smoothing some of them. Doable with Lotus 1-2-3, probably not doable otherwise.
More recent times.
Spaghetti Excel. An engineering acquaintance told me his student summer job, at an aluminum refinery, was to check and simplify their Excel spreadsheets. Apparently they had numerous spreadsheets linked to each other. I assume the main purpose was inventory control. I know I didn't envy him his task.
"Please, not just Excel." I took a class of high school students to a uni chem lab and had a small argument with a chemistry tutor who insisted the students use Excel to plot their data. I wanted them to first do it by hand with graph paper. This would have given them a much better feel for their data.
"Rinse-and-repeat Excel". I was tutoring a construction guy trying to learn maths. His job as an assistant on a high-rise construction job involved putting lots of numbers into an Excel spreadsheet. The check for this was to repeat the process and see if he got an identical result. I thank G*d his boss made him do this.
And that's it. Helped other people to use Excel, but I'm thankful that I haven't had to spend my life inputting data into spreadsheets.
>The year was 1986, pre-spreadsheets.
There were millions of spreadsheet users by 1986, as VisiCalc was released in 1979[0] and similar programs like SuperCalc[1] were also in use. They were both ported to IBM PC and saw significant use in the corporate world prior to and including 1986.
[0]https://en.wikipedia.org/wiki/VisiCalc
[1]https://en.wikipedia.org/wiki/SuperCalc
There were millions of spreadsheet users by 1986, as VisiCalc was released in 1979[0] and similar programs like SuperCalc[1] were also in use. They were both ported to IBM PC and saw significant use in the corporate world prior to and including 1986.
[0]https://en.wikipedia.org/wiki/VisiCalc
[1]https://en.wikipedia.org/wiki/SuperCalc
This is one of the things LLM's have helped me move off excel. I have an office pc that has microsoft windows + office and home pc that only has linux mint and libreoffice. Previously for anything related to excel I would by habit remote into my office pc to get it done.
I started asking how to do stuff on libreoffice on chat gpt and google gemini. And looking at how detailed explanations we have on how to use spreadsheets explained in easy to understand terms for comparably non tech users a lot of stuff became easy to do. As llm had detailed usually correct answers and suggestions. I would have learned my way to doing it anyway but LLM's brought the learning curve down from a few hours to a few min so was willing to just use libre office.
I started asking how to do stuff on libreoffice on chat gpt and google gemini. And looking at how detailed explanations we have on how to use spreadsheets explained in easy to understand terms for comparably non tech users a lot of stuff became easy to do. As llm had detailed usually correct answers and suggestions. I would have learned my way to doing it anyway but LLM's brought the learning curve down from a few hours to a few min so was willing to just use libre office.
That is a great skill to have.
When I set Win 11 or earlier version PCs for others, I always load up Void Tools "Everything" and then swing by FossHUB for the full set of tools.
Libre Office, Inkscape, and many more all go on the machine.
And then I explain what they just got and what it is worth. Almost everyone ends up being able to use the OSS tools.
Doing this saves a ton of money!
When I set Win 11 or earlier version PCs for others, I always load up Void Tools "Everything" and then swing by FossHUB for the full set of tools.
Libre Office, Inkscape, and many more all go on the machine.
And then I explain what they just got and what it is worth. Almost everyone ends up being able to use the OSS tools.
Doing this saves a ton of money!
Honestly for office just massgrave it
The rest, yes I love OSS tools on Windows.
But have fun when their important word docs get garbled
(it's an example, do not come after me with some "uuuh acually word docs open fine now")
The rest, yes I love OSS tools on Windows.
But have fun when their important word docs get garbled
(it's an example, do not come after me with some "uuuh acually word docs open fine now")
Yeah, it is not perfect.
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.
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.
>The most important aspects of all this boil down to people being able to do stuff other people would prefer they not do.
Can you elaborate please? I don't get your point.
Can you elaborate please? I don't get your point.
Yeah, I was moving fast on mobile and really could have done more.
People able to do stuff -->(other people would prefer they not do.)
Hacking of all kinds -->(software, hardware, processes, nature, the OSS mindset brings with it some perception of what could be done as well as might need to be done.)
Reverse Engineer Software -->(OSS tools often have options and workflows unavailable or that are very expensive.)
Archive -->(Some arcade games running as live distributions comes to mind)
Run Software on device or in environment not authorized (piracy, run in virtual machine, on OS not intended by developer.)
Build software -->(that may be sanctioned, illegal, or otherwise controlled.)
Repurpose hardware -->(turn router into media server, restore lost features, make hardware do extras...)
Repair -->(using the software freedoms often means repair is possible even when it is not intended to be)
Write illegal software -->(It remains possible to drop code on the net anonymously.)
Encryption-->(either novel methods or those deemed a hazard.)
That's a pretty solid list of things people may be inclined to do that other people would prefer they not do.
People able to do stuff -->(other people would prefer they not do.)
Hacking of all kinds -->(software, hardware, processes, nature, the OSS mindset brings with it some perception of what could be done as well as might need to be done.)
Reverse Engineer Software -->(OSS tools often have options and workflows unavailable or that are very expensive.)
Archive -->(Some arcade games running as live distributions comes to mind)
Run Software on device or in environment not authorized (piracy, run in virtual machine, on OS not intended by developer.)
Build software -->(that may be sanctioned, illegal, or otherwise controlled.)
Repurpose hardware -->(turn router into media server, restore lost features, make hardware do extras...)
Repair -->(using the software freedoms often means repair is possible even when it is not intended to be)
Write illegal software -->(It remains possible to drop code on the net anonymously.)
Encryption-->(either novel methods or those deemed a hazard.)
That's a pretty solid list of things people may be inclined to do that other people would prefer they not do.
Good old LibreOffice. I too fall back on that when Sheets fails me. It takes effort to justify Excel (or even Office) licenses in my workplace, but LibreOffice is available and approved for use. I won't say the 90s era interface impresses me, but it has become a shockingly solid product.
That's cool. I'm wondering if using an LLMs could make using Pandas or R as easy as Excel.
I doubt that. Pandas is stupidly powerful... for raw data, experiments, and ML model training/inference. But in my experience it rapidly becomes an esoteric box at times when you need to get data back out of it.
I don't need 95% of excel's features, and it does a lot of things that I don't want or need. But I have yet to find something that gets rid of most of the features that I don't want while keeping the things I do (which almost entirely revolve around just viewing simple .csv data files.
Primarily I want searching, sorting, and filtering, and the ability to quickly get sums/means of selected cells would be nice (although not really that necessary). I've been using Modern CSV for a while now (after discovering it on HackerNews last year sometime), and it's mostly very good (good enough that I don't regret the purchase price), but it has some stability issues and the documentation is severely lacking. But the main thing is that it's not quite good enough for me to not have to at least occasionally break out excel.
Primarily I want searching, sorting, and filtering, and the ability to quickly get sums/means of selected cells would be nice (although not really that necessary). I've been using Modern CSV for a while now (after discovering it on HackerNews last year sometime), and it's mostly very good (good enough that I don't regret the purchase price), but it has some stability issues and the documentation is severely lacking. But the main thing is that it's not quite good enough for me to not have to at least occasionally break out excel.
You should check out Row Zero (https://rowzero.io). We launched on HN earlier this year. Our CSV handling is the best on the market.
You can import multi GB csvs, we auto infer your format, and land your data in a full-featured spreadsheet that supports filter, sort, ctrl-F, sharing, graphs, the full Excel formula language, native Python, and export to Postgres, Snowflake, and Databricks.
You can import multi GB csvs, we auto infer your format, and land your data in a full-featured spreadsheet that supports filter, sort, ctrl-F, sharing, graphs, the full Excel formula language, native Python, and export to Postgres, Snowflake, and Databricks.
or skip the spreadsheet and go relational with DuckDB. Pretty cool to run directly against a set of CSVs and get performant, results in a language most of us already know and use regularly.
> Our CSV handling is the best on the market.
It’s ironic that you cite the one thing that being bad at hasn’t held Excel back. ;)
It’s ironic that you cite the one thing that being bad at hasn’t held Excel back. ;)
I suppose. But as a software developer I've never created an Excel spreadsheet that wasn't first a CSV. I do most of my own work with local data files in jq for JSON or q for CSV, then go from a CSV to an Excel spreadsheet only when it's time to communicate that data with non-programmers.
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.
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.
Google Sheets worked fine for me. The UI is intuitive and stripped down. And it has much better networking/collaboration support compared to Microsoft that has it bolted on.
I may be being silly about this, and I probably should at least try how well google sheets works for me as a regular part of my workflow, but I'd really prefer an actual local piece of software than a web app.
The finance department in a previous job rather undramatically moved over to Google Sheets from Excel after seeing the befits of the collaboration/online environment.
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)
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 think Google Sheets is nearly miraculous, with all that it can do as a web app, but it's amazing to me that anybody actually seriously using Excel in a professional capacity could migrate to it. They're not in the same weight class.
[deleted]
There's nothing silly about wanting to avoid the sandcastle-built-on-quicksand world of web applications.
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.
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.
I've used both for a long time (relatively so for Sheets given its age). The online aspect aside, Sheets does tend to work for 90% of my use cases. But that last 10%? It doesn't come close to what I can accomplish with Excel. Exotic dimensions in data, frankly better pivot table support, and perhaps most maddening, the much faster macros....
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.
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.
>But I have yet to find something that gets rid of most of the features that I don't want while keeping the things I do
The interface is customizable. You can remove any icons or group of icons on the ribbon that you don't like and you can reorganize them in any way you want. Just right click on the ribbon and click "customize the ribbon".
The interface is customizable. You can remove any icons or group of icons on the ribbon that you don't like and you can reorganize them in any way you want. Just right click on the ribbon and click "customize the ribbon".
Reading these comments, I think I might be a dinosaur, but Excel (native, Windows) has a really good keybindings UI (you press Alt, and all the key choices light up), and the ability to record actions as macros and then inspect the code is absolutely gold for automation. I know VBA is profoundly uncool and all that, but boy, if there was a better native IDE inside Excel with Copilot helping me along, I would be throwing money at Microsoft right now.
There’s a lot of finish in the Microsoft products.
Views are so much faster to pick settings in Excel. You can format tables and indent them (nested ledger) You can get higher information density.
It’s always amazing to me to wade through “how to x” in Google and see 100s of people asking for years.
Google docs and numbered headings is one of those.
Views are so much faster to pick settings in Excel. You can format tables and indent them (nested ledger) You can get higher information density.
It’s always amazing to me to wade through “how to x” in Google and see 100s of people asking for years.
Google docs and numbered headings is one of those.
The alt chords are the only good part of the keybinding UI, otherwise it's all bad unergonomic combos and difficult customization
Quotes from people 30 and above which sounds about right. Is anyone these days growing up using Excel over Google Sheets? You used to have to pirate Excel and Google just gives it away for free with a free email account.
Excel leaves GSheets and all its alternatives in the dust in terms of performance and stability.
I used to maintain MIS trackers in Google Sheets once, and when my company made the inevitable shift to MS Suite I saw an immediate improvement. FWIW I'm 25.
I used to maintain MIS trackers in Google Sheets once, and when my company made the inevitable shift to MS Suite I saw an immediate improvement. FWIW I'm 25.
Certainly compared to early Google Sheets this is true, and it may be that first impression that a lot of older people still remember.
Google Sheets today is totally adequate for most people's spreadsheet needs. I'd believe there are cases where Excel is still better, but they are at the extreme end of "power user" use cases.
Google Sheets today is totally adequate for most people's spreadsheet needs. I'd believe there are cases where Excel is still better, but they are at the extreme end of "power user" use cases.
For sure. Google sheets is good enough to be tolerable.
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).
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).
Well, not all its alternatives. There's one spreadsheet out there that has better performance than Excel: https://rowzero.io/home
How is its offline performance?
I think you’re talking about it in a professional environment. That won’t matter if the people are growing up on GSheets today & demand that tool from their employer. Very old tale in SW.
GSheets are honestly a nightmare to use in case you have a nontrivial volume of data to work on. It won't do for most enterprise uses, especially in BI.
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.
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.
Employers will tell them that their serious sheets only work in excel and it’s similar enough that they’ll figure it out and they’ll be right on both counts.
Depends on the profession. The company might shell out money for accounting to use excel. But PMs, engineers, TPMs, etc etc are likely to be told “hey we’re using google workplaces and aren’t going to buy you an excel license” unless you can make a very convincing case. That represents a shrinking pie for Excel even if specific professional use remains on Excel while everyone else moves on. Similar stuff happened with things like COBOL, IBM mainframes, etc. That’s why Microsoft competes with their 365 offering, but Google really put a dent in Microsoft’s near monopoly on OS+productivity tools that they built up and cemented in the 90s/early 00’s.
In my experience it depends more on the company you’re in than on the profession.
I worked for an MSP in Europe, so IT provider.
No company used Google Workspace. All where Office 365.
No company used Google Workspace. All where Office 365.
Equally I’ve never worked for a company in my life that uses office or 365. At most in one org the CFO and his direct report had office licenses for excel.
In working for a European company right now that is a pure google workspace shop. (Though I work remote and am not based in Europe myself.)
I’ve got zero idea how to use excel because I’ve simply never worked for an org that has deployed Microsoft products and I’m nearing 40.
Wild how different our experiences can be. I’d be totally open to trying out Microsoft products but it’s just never come up. In the same vein, I’ve never used windows in my career either (though I have administered windows server but that was only due to it being a requirement for some VMware stuff and it was treated like a leper.)
I started my career with Linux and most roles since have deployed/provided MacBooks with OSX.)
In working for a European company right now that is a pure google workspace shop. (Though I work remote and am not based in Europe myself.)
I’ve got zero idea how to use excel because I’ve simply never worked for an org that has deployed Microsoft products and I’m nearing 40.
Wild how different our experiences can be. I’d be totally open to trying out Microsoft products but it’s just never come up. In the same vein, I’ve never used windows in my career either (though I have administered windows server but that was only due to it being a requirement for some VMware stuff and it was treated like a leper.)
I started my career with Linux and most roles since have deployed/provided MacBooks with OSX.)
I love GSheets for convenience. But as soon as you're doing anything large and complex, GSheets might as well not even exist. It's simply not viable.
GSheets is the good enough factor and the collaborative features were baked in from the start. I feel like MS struggles a bit in that respect. Look at the instructions for collaborating in Excel: https://support.microsoft.com/en-us/office/collaborate-on-ex...
I’ve had the pleasure of investing many hours across excel and gsheets. I’m currently at an org that uses MS suite and excel collaboration across OneDrive & Sharepoint is almost seamless now as long as long as you’re on the cloud
But is the cloud version of Excel feature parity with the desktop for the pro users that claim that Google sheets isn't good enough? If the cloud version of Google sheets is the same as the cloud version of Excel, then that's not the same thing at all.
Yes as long as you are running your spreadsheet on the desktop version. You can open them up on the browser version too which is total trash but you’ve got full functionality of your cloud spreadsheets while on the desktop app
I don't think people are remotely aware how Good MS tools are atm when it comes to collaboration and integration with their "other" suit of tools. Yes, it's ugly sharepoint under the hood somewhere, but for all intents and purposes it looks and works like magic when I'm collaborating in real-time with my coworkers over any sort of MS document. This whole "real time collaboration" comment as a reason to prefer some half-baked and confusing "GSheets" web app is frankly confusing.
Though, now that I think about it, it kind of makes sense: We are in an industry where the newcomers are being indoctrinated via evangelists and overall Schadenfreude, into using half-baked "IDEs" like VSCode.
Though, now that I think about it, it kind of makes sense: We are in an industry where the newcomers are being indoctrinated via evangelists and overall Schadenfreude, into using half-baked "IDEs" like VSCode.
Our team runs into errors (changes not syncing, etc.) on a regular basis 'collaborating' with Excel. definately doesn't work like magic in my experience.
I have private information in my files, and I don't want to share it with google. Google will scan it, use it for ad profiling, sell to whomever and store all commits for eternity. Quote probably government has access too.
And, of course, they will use it for AI training, which could be reverse-engineered in the future to extract training data.
And, of course, they will use it for AI training, which could be reverse-engineered in the future to extract training data.
Exactly.
I always have at least one machine setup with all local tools and storage.
Any new ideation and certainly anything private gets done on that computer first.
I always have at least one machine setup with all local tools and storage.
Any new ideation and certainly anything private gets done on that computer first.
Free isn’t good enough. Sheets has stupid limitations like a hard cap of 10M or so cells per document.
Immediately focusing on the distinction between Microsoft Excel Proper and competing implementations with essentially similar functionality is so weird to me. I feel a fondness for this article despite not having used Microsoft Excel itself for like two decades. The point is the larger genre, and the empowerment of programming and data management capabilities it creates for regular users.
I worked for an MSP in Europe, so IT provider.
No company used Google Workspace. All where Office 365.
You use what the company wants you to use :)
If you zoomerettes try to use your own google account you will get flagged for data extraction. :)
Also the web version of office is free, did you know? https://www.office.com/
No company used Google Workspace. All where Office 365.
You use what the company wants you to use :)
If you zoomerettes try to use your own google account you will get flagged for data extraction. :)
Also the web version of office is free, did you know? https://www.office.com/
But then you have all the usability issues of a complex app shoehorned into a browser. I'll always use a native application when it's available.
Not disagreeing, but I find it very ironic that there’s little difference in performance between Excel as a native app and as a web app. I don’t know if that mostly reflects the technical prowess of the web dev team or the inefficiencies of the native app.
That's incorrect. Not only is the web app drastically trimmed of features, but is also in no way a match to the native app in performance.
You can test for yourself - try doing some complex operations on large datasets on both. See which one performs better.
You can test for yourself - try doing some complex operations on large datasets on both. See which one performs better.
Sheets is unfortunately mostly better than Numbers.
Excel is free online too.
My Excel to the rescue story is the time I worked in a locked down environment with limited access to programming tools but needed to make physics-based simulators.
I made an aircraft flight model that made heat maps of line of sight vectors to the ground as a plane banked and flew its looping flight path over a city. I included an overhead view animation tab by plotting the lat/lon over a scatter plot with a map as a background image and walking over each point via the arrow keys. Wrote some VB to output the image frame to files then stitched them together as a gif. Funny enough it worked great on everyone’s machine except the conference room computer attached to the projector. Turns out it was due to it not having a printer driver installed so some screen inch to pixels system variable wasn’t set.
I did all of the problems in the Fundamentals of Astro dynamics book (BMW) via excel by using the cel copy via mouse drag to perform iteration based calculations.
A co-worker made a complete battlefield simulation in excel that was amazing.
Another shrunk the row and columns cells into pixel size and made some pretty cool looking animations by using cell formatting to turn them on/off with color.
Today, the only modern toolset that would come close to being able to made those examples as quickly would be Jupyter Notebooks. Another tool “professional” coders hate. Maybe Matlab with some costly modules but that breaks down once you leave its linear algebra comfort zone.
I truly hate Microsoft but Excel is an amazing piece of software. Which funny enough started on a Mac.
I made an aircraft flight model that made heat maps of line of sight vectors to the ground as a plane banked and flew its looping flight path over a city. I included an overhead view animation tab by plotting the lat/lon over a scatter plot with a map as a background image and walking over each point via the arrow keys. Wrote some VB to output the image frame to files then stitched them together as a gif. Funny enough it worked great on everyone’s machine except the conference room computer attached to the projector. Turns out it was due to it not having a printer driver installed so some screen inch to pixels system variable wasn’t set.
I did all of the problems in the Fundamentals of Astro dynamics book (BMW) via excel by using the cel copy via mouse drag to perform iteration based calculations.
A co-worker made a complete battlefield simulation in excel that was amazing.
Another shrunk the row and columns cells into pixel size and made some pretty cool looking animations by using cell formatting to turn them on/off with color.
Today, the only modern toolset that would come close to being able to made those examples as quickly would be Jupyter Notebooks. Another tool “professional” coders hate. Maybe Matlab with some costly modules but that breaks down once you leave its linear algebra comfort zone.
I truly hate Microsoft but Excel is an amazing piece of software. Which funny enough started on a Mac.
I work adjacent to a mid sized engineering department that develops both hardware and software, for measurement equipment.
The managers use Excel, as one might expect, although at this point it might be equally accurate to say "spreadsheets" generically. I'm not sure how many of them use advanced features that are unique to Excel. They will use the one with the least friction. With that said, Excel probably still has the most finely tuned UI.
The traditional engineers use Excel. Very few of them program. The ones who can do it well enough to get paid for it, have joined the software industry. The rest are pretty adamant that programming won't get the job done quicker or more reliably than Excel.
The software engineers use Excel. They're good at whatever their role is within the software team, but they use Excel for the same kinds of short-term or one-off problem solving that everybody else uses it for.
Do some spreadsheets get too big and unwieldy for their own good? Sure. But that would also be true if you let the managers and traditional engineers write their own code for solving the same kinds of problems. I know this because I write that kind of code. Nothing will ever bridge the gap between small and large projects, that exists in most mature organizations.
The managers use Excel, as one might expect, although at this point it might be equally accurate to say "spreadsheets" generically. I'm not sure how many of them use advanced features that are unique to Excel. They will use the one with the least friction. With that said, Excel probably still has the most finely tuned UI.
The traditional engineers use Excel. Very few of them program. The ones who can do it well enough to get paid for it, have joined the software industry. The rest are pretty adamant that programming won't get the job done quicker or more reliably than Excel.
The software engineers use Excel. They're good at whatever their role is within the software team, but they use Excel for the same kinds of short-term or one-off problem solving that everybody else uses it for.
Do some spreadsheets get too big and unwieldy for their own good? Sure. But that would also be true if you let the managers and traditional engineers write their own code for solving the same kinds of problems. I know this because I write that kind of code. Nothing will ever bridge the gap between small and large projects, that exists in most mature organizations.
Based on this, I'd love to brainstorm here on HN about what a next-generation Excel could look like, one that keeps Excel’s core strengths without expanding into database like features found in tools like Airtable. Here are a few ideas:
1. Clear Separation between UI/UX and Backend: By separating the user interface from backend processes—perhaps as a module or library—Excel could maintain its clean, familiar interface while supporting more complex calculations and data handling in the background. This concept is somewhat akin to “Microsoft Excel Services.”
2. Multi-Language Formula Support: Similar to how VSCode supports multiple programming languages, Excel could allow users to choose between languages for cell formulas. Many users are comfortable with the current formula syntax, but it feels outdated, and even Google Sheets has (obviously?) largely replicated this old model. Allowing for different languages, while keeping the Directed Acyclic Graph (DAG) structure, could enable more advanced and flexible workflows.
3. Enhanced Data Types and Representations: Cells or groups of cells could support stronger data types, richer formatting, and custom representations, like embedded charts.
4. Integrated Data Connectivity: Excel could come with built-in tools to connect to external data sources and export data in structured formats, perhaps managed with an external orchestrator. I know you can do this with Excel and some other tools but I would like to just mark a cell and indicating that it can be consumed in a specific endpoint.
5. No artificial limits to the number of columns and rows.
1. Clear Separation between UI/UX and Backend: By separating the user interface from backend processes—perhaps as a module or library—Excel could maintain its clean, familiar interface while supporting more complex calculations and data handling in the background. This concept is somewhat akin to “Microsoft Excel Services.”
2. Multi-Language Formula Support: Similar to how VSCode supports multiple programming languages, Excel could allow users to choose between languages for cell formulas. Many users are comfortable with the current formula syntax, but it feels outdated, and even Google Sheets has (obviously?) largely replicated this old model. Allowing for different languages, while keeping the Directed Acyclic Graph (DAG) structure, could enable more advanced and flexible workflows.
3. Enhanced Data Types and Representations: Cells or groups of cells could support stronger data types, richer formatting, and custom representations, like embedded charts.
4. Integrated Data Connectivity: Excel could come with built-in tools to connect to external data sources and export data in structured formats, perhaps managed with an external orchestrator. I know you can do this with Excel and some other tools but I would like to just mark a cell and indicating that it can be consumed in a specific endpoint.
5. No artificial limits to the number of columns and rows.
6? Explicit versioning of spreadsheets, eg a Commit to GitHub button. 365 saves continuously but doesnt have the mental step of making you record what changed. Along the same lines, diff for spreadsheets that supported diff-by-value and diff-by-formula.
7? Beef up the recommended pivot tables. Not to jump on the AI bandwagon, but any table that has Sales$ and dates is ripe for suggesting sales by qtr, week etc. Let the AI inspect the table and make suggestions.
8. Beef up the programmability. The Record Macro feature emits VBA but the code is very literal (eg it sees you move to row 12345, and records that, not understanding that what you mean is 'move to the last row') and the IDE is primitive. Fold in copilot experience to the IDE, modernize the UI, and allow macros to be integrated with github instead of buried in some personal.xlb file that is all too easy to lose.
7? Beef up the recommended pivot tables. Not to jump on the AI bandwagon, but any table that has Sales$ and dates is ripe for suggesting sales by qtr, week etc. Let the AI inspect the table and make suggestions.
8. Beef up the programmability. The Record Macro feature emits VBA but the code is very literal (eg it sees you move to row 12345, and records that, not understanding that what you mean is 'move to the last row') and the IDE is primitive. Fold in copilot experience to the IDE, modernize the UI, and allow macros to be integrated with github instead of buried in some personal.xlb file that is all too easy to lose.
I worked in finance professionally for 7 years before I started writing code for money, so I would say I am very familiar with the tool.
For the specific set of problems it is designed to solve, its like shooting the best sniper rifle ever made -- point, calibrate, pull trigger, win.
For any other problems outside of its scope, its like trying to break the world record for Nurburgring while driving a short bus.
For the specific set of problems it is designed to solve, its like shooting the best sniper rifle ever made -- point, calibrate, pull trigger, win.
For any other problems outside of its scope, its like trying to break the world record for Nurburgring while driving a short bus.
I use Numbers for my day-to-day spreadsheet stuff, part of Apple's iWork suite with Pages and Keynote.
The UI/UX is so much better than Excel's and you can export to .xlsx format.
Don't get me wrong--there are some projects that require the functionality that Excel has. Using it gives me 90's software PTSD but sometimes you have no choice.
The UI/UX is so much better than Excel's and you can export to .xlsx format.
Don't get me wrong--there are some projects that require the functionality that Excel has. Using it gives me 90's software PTSD but sometimes you have no choice.
And what do you do for a living may I ask? Accountant, Actuary, trader? I only ask if you are using some of the advanced features, which is where the others start to fall away.
Numbers is a fine way to keep a shopping list, or a household budget, I'm sure
Numbers is a fine way to keep a shopping list, or a household budget, I'm sure
> Numbers is a fine way to keep a shopping list, or a household budget, I'm sure
Don't be fooled by the marketing—Numbers has 90% of Excel's core functions; it even had RegEx before Excel did. IMHO, Numbers UI/UX is dramatically better than Excel's.
Of course, it doesn't have Excel's advanced features or access to plugins or to Python scripts. The users who need that know they need Excel… but you can go surprisingly far with Numbers.
Like I originally said, there are some tasks where you absolutely need Excel.
Don't be fooled by the marketing—Numbers has 90% of Excel's core functions; it even had RegEx before Excel did. IMHO, Numbers UI/UX is dramatically better than Excel's.
Of course, it doesn't have Excel's advanced features or access to plugins or to Python scripts. The users who need that know they need Excel… but you can go surprisingly far with Numbers.
Like I originally said, there are some tasks where you absolutely need Excel.
Does Numbers run well on a PC?
I'm the opposite. I cannot stand Apple's productivity software, and I get irrationally mad when something tries to open those.
An acquaintance I used to live near has a custom pool in her yard that she designed and specified via Excel! She's a programmer, so she could have used a wide range of tools but Excel was what she reached for and it evidently did the trick nicely.
The thing that stands out to me in these stories is that spreadsheet programs are a (1) the most common site of programmability that features in anyone's lives, even non-programmer; and (2) for many tasks, spreadsheets sit at some kind of local optimum in a tradeoff between simplicity and power. (There's surely something for engineers and designers to learn from the second point.)
It seems like a connection worth celebrating, between people like us and the mostly non-programming public— a little piece of overlap between two worlds.
The thing that stands out to me in these stories is that spreadsheet programs are a (1) the most common site of programmability that features in anyone's lives, even non-programmer; and (2) for many tasks, spreadsheets sit at some kind of local optimum in a tradeoff between simplicity and power. (There's surely something for engineers and designers to learn from the second point.)
It seems like a connection worth celebrating, between people like us and the mostly non-programming public— a little piece of overlap between two worlds.
The flight sim Easter egg baked into Excel 97 got me hooked!
https://youtu.be/-gYb5GUs0dM?si=vzOGscnTURqhdyDe
Warning - this video shows Clippy, the very irritating paperclip!
https://youtu.be/-gYb5GUs0dM?si=vzOGscnTURqhdyDe
Warning - this video shows Clippy, the very irritating paperclip!
You're cleared for takeoff: https://rezmason.github.io/excel_97_egg
I think of Excel as a neat example of a rare local minimum in the great programming space. I think R gets to something close like this too.
You can technically accomplish about any programming task you want in it, albeit with poor ergonomics for anything sufficiently complicated, and a small but real push in that area of work will lead you to use a more accepted form of "programming".
However, due to whatever environment, desired or perceived skillsets (or limitations), other pressures, people stay and remain with that local tooling minimum for things that should have outgrown it. If you ever meet an office's "excel person" you instantly understand this phenomena.
You can technically accomplish about any programming task you want in it, albeit with poor ergonomics for anything sufficiently complicated, and a small but real push in that area of work will lead you to use a more accepted form of "programming".
However, due to whatever environment, desired or perceived skillsets (or limitations), other pressures, people stay and remain with that local tooling minimum for things that should have outgrown it. If you ever meet an office's "excel person" you instantly understand this phenomena.
R is mostly benefiting from network effects. Everyone in the life sciences uses it (I think economists mostly use Statista and engineers/physicists seem to use a lot of MatLab?), which means that all the things that they need get R libraries (and blog posts explaining how to do them, and publications validating their use, etc.). And the way that academic scientists work mean that most of the downsides of R don't actually matter.
I will completely agree with almost any list of deficiencies that you come up with for R. But I will disagree that almost anything on that list actually matters for an academic lab using it to conduct analyses.
As for it's use outside of academia, I couldn't comment.
I will completely agree with almost any list of deficiencies that you come up with for R. But I will disagree that almost anything on that list actually matters for an academic lab using it to conduct analyses.
As for it's use outside of academia, I couldn't comment.
I much prefer ggplot over other options!
I'm an Excel person who is branching into PowerShell. Similar "no tools required" approach.
I mean... I have some spreadsheets that are pretty complicated and almost certainly could be a fully fledged program but, well it's already there and I don't need to figure out whatever framework / library I need to present the data as a PDF, excel already does that...
I 100% get the appeal of excel for many tasks and realistically when used as a tool it is extremely powerful and removes a lot of things (like how to display the data) out of what I need to care about.
I 100% get the appeal of excel for many tasks and realistically when used as a tool it is extremely powerful and removes a lot of things (like how to display the data) out of what I need to care about.
See https://www.felienne.com/public-appearances and ctrl-f for Excel. Especially the videos, like https://www.youtube.com/watch?v=bdfNvYPxkOY . Then have a gander at https://support.microsoft.com/en-us/office/lambda-function-b...
I’ve only ever used Libre(open) Office Calc since I’ve never paid for or bothered to pirate office before. What can Excel do that Calc can’t?
I’ve never done anything crazy heavy with it, but functions and stuff work fine for me I guess.
I’ve never done anything crazy heavy with it, but functions and stuff work fine for me I guess.
I use Calc on my personal machine.
> What can Excel do that Calc can’t?
For one, a working copy paste. Seriously, I’ve lived with a copy paste bug in LibreOffice Calc (Windows) for years (it wasn’t yet fixed as of a few months ago). It will either paste an older copy or not paste anything even though I just hit Ctrl+C (sometimes multiple times) within Calc. This is one of the most irritating things about Calc.
Fonts and formatting is another thing that Calc miserably fails at in relation to copy paste. Multiple cells will look very different even though the font, size, etc., will appear the same in the dropdowns below the menus (when these cells are in focus). LibreOffice Calc, in many ways, portrays the worst of what one would expect from an open source project (I say this as a supporter/donor of Document Foundation).
The other part about what Excel can do that Calc can’t is that Microsoft (at least with the MS365 subscription version) has been adding more functions to improve older functions and features. I don’t remember everything, but SEQUENCE and XLOOKUP are two functions that come to mind on this aspect. LibreOffice Calc lags behind Excel on functions by several years.
LibreOffice Calc, though it’s a lot newer/younger than Excel, also has ~weird~ different keyboard shortcuts compared to Excel (e.g. adding a new line within a cell is Ctrl+Enter whereas it’s Alt+Enter in Excel; there are many more like this).
Nevertheless, I use Calc because I can’t bother to pay Microsoft and since Excel might be the only application that could be of value to me in its Office offerings (MS Word is total crap, PowerPoint isn’t as keyboard friendly as I’d like it to be, and Outlook is another total piece of crap).
> What can Excel do that Calc can’t?
For one, a working copy paste. Seriously, I’ve lived with a copy paste bug in LibreOffice Calc (Windows) for years (it wasn’t yet fixed as of a few months ago). It will either paste an older copy or not paste anything even though I just hit Ctrl+C (sometimes multiple times) within Calc. This is one of the most irritating things about Calc.
Fonts and formatting is another thing that Calc miserably fails at in relation to copy paste. Multiple cells will look very different even though the font, size, etc., will appear the same in the dropdowns below the menus (when these cells are in focus). LibreOffice Calc, in many ways, portrays the worst of what one would expect from an open source project (I say this as a supporter/donor of Document Foundation).
The other part about what Excel can do that Calc can’t is that Microsoft (at least with the MS365 subscription version) has been adding more functions to improve older functions and features. I don’t remember everything, but SEQUENCE and XLOOKUP are two functions that come to mind on this aspect. LibreOffice Calc lags behind Excel on functions by several years.
LibreOffice Calc, though it’s a lot newer/younger than Excel, also has ~weird~ different keyboard shortcuts compared to Excel (e.g. adding a new line within a cell is Ctrl+Enter whereas it’s Alt+Enter in Excel; there are many more like this).
Nevertheless, I use Calc because I can’t bother to pay Microsoft and since Excel might be the only application that could be of value to me in its Office offerings (MS Word is total crap, PowerPoint isn’t as keyboard friendly as I’d like it to be, and Outlook is another total piece of crap).
I use LibreOffice on Linux and don't have any copy/paste or fonts and formatting issues like you are describing. I wouldn't be surprised if such bugs get fixed more quickly on Linux because Linux users don't have an easy way to use Excel, while the vast majority of Windows users do use Excel so there are fewer LibreOffice for Windows users complaining.
Excel does have more functions but 90% of people don't need those. If you do, you do.
Excel does have more functions but 90% of people don't need those. If you do, you do.
> It will either paste an older copy or not paste anything even though I just hit Ctrl+C (sometimes multiple times) within Calc.
Weird. I've used Calc extensively on Windows and Linux and have never come across this
Weird. I've used Calc extensively on Windows and Linux and have never come across this
Excel also has that program synthesis algorithm to fill cells following a pattern. I haven't seen it anywhere else.
I believe Numbers has what's you're talking about [1]:
[1]: https://support.apple.com/guide/numbers/autofill-cells-tan0e...
[1]: https://support.apple.com/guide/numbers/autofill-cells-tan0e...
No, that sounds like conventional autofill.
In Excel the function is called Flash Fill.
If you haven't before, try Flash Fill. It seemed like black magic back when LLMs were not a thing.
In Excel the function is called Flash Fill.
If you haven't before, try Flash Fill. It seemed like black magic back when LLMs were not a thing.
I’ve used Excel and Calc and the short answer is ‘everything’. Excel is faster, more reliable and has a much bigger community.
Calc is ok if you want to work with small spreadsheets and don’t care about the occasional bug.
Calc is ok if you want to work with small spreadsheets and don’t care about the occasional bug.
not the parent, but 'everything' is a mostly unhelpful answer.
A few important concrete examples would be much more interesting. In fairness, you did somewhat, but I would be interested in some more details.
A few important concrete examples would be much more interesting. In fairness, you did somewhat, but I would be interested in some more details.
It's like asking what are the differences between Visual Studio and Notepad++. Literally >90% of the tools in Excel don't exist in Calc. And there are big ones in the list (eg. pivot table, vba macros, solver), not just small feature..
I mean this literally: Everything you can do in Calc, Excel is better at in either UX or performance, usually both. Even typing formulas in cells is snappier in Excel.
A very basic example, Calc doesn't have tables. That's enough for me to not want to use it, but there are probably a dozen of those for me.
FWIW, a permanent 1-machine Excel-only license key is pretty affordable on G2A et al.
Right on time for the Excel World Championships... https://www.youtube.com/watch?v=e4NP5FBB2G0
most people in tech don't get what Excel is imo. start with the idea that it's a fully featured virtual machine that uses a different interface metaphor than a command line or windowing. it's useful to think of it as an abstraction layer where business runs, it's where value is demonstrated. those user spreadsheets are computers/hosts/vms and I'd argue that's often the disconnect between what technologists think they are supporting and what users think should be supported.
of course custom code is better at pretty much anything. I've been a unix user since the bsdi days and so to me spreadsheets are a cruel toy running in a blue tinted mental prison, but when you see excel as a different and sophisticated UX metaphor for a fully featured machine that the user uses for raw arithmetic computation, and as an alternative to a command line or a browser, it's much easier to respect. that's absolutely essential for understanding it and its users.
the thing about excel is if you don't use it i guarantee you work for someone who does as the tabular metaphor is the system of the world. even if reality is more complex and needs more complex objects to model it, human beings ultimately organize around the contents of spreadsheets. hand wavy, but I don't know how else to tell developers and product people they need to take excel seriously.
of course custom code is better at pretty much anything. I've been a unix user since the bsdi days and so to me spreadsheets are a cruel toy running in a blue tinted mental prison, but when you see excel as a different and sophisticated UX metaphor for a fully featured machine that the user uses for raw arithmetic computation, and as an alternative to a command line or a browser, it's much easier to respect. that's absolutely essential for understanding it and its users.
the thing about excel is if you don't use it i guarantee you work for someone who does as the tabular metaphor is the system of the world. even if reality is more complex and needs more complex objects to model it, human beings ultimately organize around the contents of spreadsheets. hand wavy, but I don't know how else to tell developers and product people they need to take excel seriously.
Most people do get that and why it's useful. But it's like ssh-ing into a vm to do anything in production. It works, but goes against any engineering principle we have. We write bespoke scripts and I think no one would begrudge anyone trying to do quick a quick computation on anything tabular. But then you got complicated business processes that are held together by spreadsheets and it's a nightmare scenario when you know how much people trust the computer. It's easy and fast, but we'd like some more reliability.
I grew out of it.
I started to really loath the spreadsheet data model. "it's a big bag of cells" was not really doing anything for me. I started wanting better data structures and programing environments to work on that data.
For the data storage and basic calculations on that stored data role, I mainly use a relational database, most of what I wanted in a spreadsheet was row level security, that is, for my rows to stick together(one to many bad sorts I guess), and relational databases provided this in spades.
I started to really loath the spreadsheet data model. "it's a big bag of cells" was not really doing anything for me. I started wanting better data structures and programing environments to work on that data.
For the data storage and basic calculations on that stored data role, I mainly use a relational database, most of what I wanted in a spreadsheet was row level security, that is, for my rows to stick together(one to many bad sorts I guess), and relational databases provided this in spades.
I have never really been proficient in Excel and I've always sort of been drawn to Python+Pandas+DataWranglers, but I am sorta interested in Python for Excel when it is released for Mac. I'll at least give it a shot!
Have you tried getgrist.com? It's a relational database that looks like a spreadsheet and has granular row level security. And also the language of formulas is Python.
Excel can be really great — it’s been said that a huge amount of the world‘s programming is actually done in excel (summing a column of numbers is, after all, a very primitive programme).
I wish there were better tools to help excel users migrate to more formal coding. Something that allows the immediate visibility and accessibility of Excel code, but avoids some of the problems of updating a formula in one place, but missing another, allowing better testing, and type safety for data.
I wish there were better tools to help excel users migrate to more formal coding. Something that allows the immediate visibility and accessibility of Excel code, but avoids some of the problems of updating a formula in one place, but missing another, allowing better testing, and type safety for data.
Best part: Excel supports your example and many other similar quality of programmers life use cases and has been for years if not decades (e.g. named ranges and tables). For some reason people don’t use them.
A downright comical number of analytics products are crude reimplementations of lesser-known Excel features. A rudimentary understanding of pivot tables or "goal seek" can be enough to blow minds even among an audience that has used Excel on a daily basis for decades. Spreadsheets, like word processors and presentation tools, are so omnipresent that organizations tend to assume their operation is absorbed through osmosis, and therefore fail to invest in training.
There's PowerQuery, built into Excel. It can do some great stuff (love me some fuzzy join) but the ergonomics are apocalyptic.
This is actually the root problem of trying to improve or extend Excel--it has a truly ancient, horribly broken sharing/ipc/embedding model that is integrated into everything and can't be easily fixed or worked around.
This is actually the root problem of trying to improve or extend Excel--it has a truly ancient, horribly broken sharing/ipc/embedding model that is integrated into everything and can't be easily fixed or worked around.
Power Query/M is the only functional language I've used, a couple years ago. I actually quite liked it, I even built up a collection of my own functions.
It's just a pity the editor is literally worse than Notepad. And the implementation wants to reload a file twenty times. And the security stuff doesn't really work, so you're constantly turning that off. And and and.
It's just a pity the editor is literally worse than Notepad. And the implementation wants to reload a file twenty times. And the security stuff doesn't really work, so you're constantly turning that off. And and and.
I think the main feature of excel that makes it the killer app it is, is that it is extremely approachable to non technical people. Making it more like programming erodes the core feature that motivates its use.
No joke, I built a Excel compiler once. All functions written became legit code you could compile down to a binary. But wow, I learned a lot about how complex that could get... my intermediate language was technically readable, but when every cell is a function, it got so big it would break the target binary compiler unless I split it up. Good times though....
I guess when you add type safety and tests to an app like Excel, it becomes so much closer to programming languages that it makes more sense to ditch the app and just write code directly.
Even today, complex logic in Excel is mostly done through VBA, JavaScript, Python and the like.
Even today, complex logic in Excel is mostly done through VBA, JavaScript, Python and the like.
I got into professional programming via VBA in Excel
Its really disappointing that VBA stopped improving since 20 years ago. Imagine if you could embed C# or even better F# in workbooks, and also have a way to better way to package libraries. We wouldn't see Python notebooks.
I wrote something to make it simple to embed C++ in Excel. It is useful for pushing business logic into platform independent code that can be integrated into back end production systems. One bonus is the original spreadsheet has unit tests vetted by the business users.
https://github.com/xlladdins/xll
Because I’m so used to excel, I really have a hard time using sheets, it’s different enough to be annoying and easy enough to export to xls to open in excel and do things the way I want to.
One thing I’ve had success with lately is chat-gpt 4o to manipulate large sheets. Sometimes it is really dumb and ruins my data, so always keep the last iteration handy… Sometimes it does some really great things, especially comparing multiple excel files.
One thing I’ve had success with lately is chat-gpt 4o to manipulate large sheets. Sometimes it is really dumb and ruins my data, so always keep the last iteration handy… Sometimes it does some really great things, especially comparing multiple excel files.
Fun facts, when Excel was launched by both Steve Jobs of Apple and Bill Gates of Microsoft back in 1985 at Tavern on the Green, New York, Excel has 16,384 rows and 256 columns, and now original Excel's rows now exactly matched the Excel's current columns of 16,384 (2^14).
Another fun facts, on average people spent 10% of their working life using Excel.
Another fun facts, on average people spent 10% of their working life using Excel.
It's unfortunate that folks haven't had the chance to try the various other alternatives --- Informix WingZ had quite nice charts, Lotus Improv was quite different, and only Quantrix has survived, but not many folks get to use it since its so expensive to license a seat. I wish the opensource Flexisheet would be reworked so that it would compile and run again.
FWIW, I am building another alternative. We are very, very, very far away from Excel.
But TBH I think that's true for anything else that is not Excel or Google sheets.
Zoho deserves a special mention and lots of other good folks have created fantastic things like rows ir grid.is
There was a day when Excel was used as a password manager. It might have been password protected. It might not have.
Soon after I started my first IT job, my boss had me fill out a spreadsheet with everybody’s local desktop password so we could do updates when they aren’t around. It was a very awkward week asking people for their passwords. That was almost 30 years ago, and I still remember a few people’s passwords.
Then we had fiber (FTTH) installed in my building, the installation company delivering the routers wrote everybody's router username, password and SSID with a whiteboard marker on the outside of the door, "to make the installation easier for the technicians".
Still happens lol
Some companies dont want to learn a new tool
Or pay for a new tool like itglue/bitwarden/keeper
Some companies dont want to learn a new tool
Or pay for a new tool like itglue/bitwarden/keeper
The magic of Excel is that everyone has it and it does enough for most cases.
Yes, some things could be done better with a separate application or custom software, but that requires approval and contracts etc.
With Excel you can just build that crap yourself and share it or not.
Yes, some things could be done better with a separate application or custom software, but that requires approval and contracts etc.
With Excel you can just build that crap yourself and share it or not.
It may well be on HN that I read so-and-so's rule: It doesn't matter what the users say they want, they want Excel.
Gratitude and an upvote to the person who can attach a name and citation to the rule.
Gratitude and an upvote to the person who can attach a name and citation to the rule.
40 years ago the spreadsheet was the killer app of the fledgling device known as the personal computer, and now it's an indelible part of many people's daily life.
My spouse has a background in engineering and health sciences and is an Excel fan. I do IT support, and I kind of hate Excel, but I kind of love Apple's Numbers app.
I've exclusively used Numbers for as long as the app has been around. It meets all of my needs, including almost seamless Excel compatibility for imports and exports should the need arise.
The IT industry overall remains similarly entrenched. Enterprise software vendors insist on Windows dependency, staying tethered to outdated standards; upholding an inefficient status quo that serves only MSFT, developers, and technicians—not users nor progress.
The IT industry overall remains similarly entrenched. Enterprise software vendors insist on Windows dependency, staying tethered to outdated standards; upholding an inefficient status quo that serves only MSFT, developers, and technicians—not users nor progress.
And us industry standard excel users hate when we send you Excel sheets (for a good reason) and then you use and edit them in .numbers, and then send them back as .numbers without a care in the world ... often we lose all the background goodness we built in (often designed to make your life easier!) ... you in the general sense ... calms shaking rage
Numbers could be nice if it was fast. Unfortunately it’s dog slow. It’s good enough with the simplest formulas, but once you try to actually use it for anything, it becomes unbearable.
Certainly Numbers 14.2 on a recent Mac isn't slow.
Not saying you're doing this but it's not uncommon for someone to say something is slow when it's a version from 10 years ago.
Not saying you're doing this but it's not uncommon for someone to say something is slow when it's a version from 10 years ago.
Yea, people grow up with rashes on their butts too, stop glorifying this steaming pile of s/w doo doo...
Obligatory Krazam:
https://youtu.be/xubbVvKbUfY
https://youtu.be/ICp2-EUKQAI
https://youtu.be/xubbVvKbUfY
https://youtu.be/ICp2-EUKQAI
Excel is great but there’s a large audience who would benefit from something simpler and more intuitive. That’s what we are trying to build at Klaro (klaroapp.com)
This is unendurable, this article didn’t actually say what are the names of the babies! To describe entire process and then leave out the result is just bad journalism.
Imagine an accountant coming on here and telling you that you don't need vi, emacs, sublime text or VSCode. You certainly don't need your IDEs. After all it's perfectly possible to code in Notepad.
You also don't need your languages. BASIC was perfectly good.
The killer feature of Excel for financial modelling, over 'proper' software, databases etc is portability and auditability.
Everything I do at work is subject to external audit. Every audit firm in the world has Excel. The tax advisors have Excel too, as to the tax authorities. Apprentices are trained in Excel. The people I hire may not have used our ERP, but they have all used Excel. It is the one constant in our world. The actual accounting records are in an ERP, but all of the outputs are in Excel. I have worked at several multinationals and several SMEs. Excel was everywhere.