'I grew up with it': readers on the enduring appeal of Microsoft Excel
theguardian.com
theguardian.com
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.
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.
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?
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.
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.)
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.
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
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.
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.
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.
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.
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.
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.
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.
And you wouldn't need to, you would extract a much smaller subset to Excel and enjoy a superior user interface further analysing that
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 the non-PIM teams agree, and they are a few orders of magnitude bigger and more important.
There also is no "fireable offence" structure here, we aren't a US-company and we have strong labour protections here. They themselves chose how they want their processes to work, and none of them ended up with Excel in the main process loop, anywhere.
Perhaps this is something you cannot imagine, but over here, this has been the standard for years. And it pays dividends.
This does not mean excel doesn't exist or isn't used outside of the main processes/loops/flows. But that is what I wrote in my first comment here, which people seem to skip over.
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?
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.
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
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.
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 hate Excel for many reasons but it is king for a reason.
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.
Excel is near universal and flexible. It’s not a hammer. It’s a swiss army knife.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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
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?
Pdf is much less useful.
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 also cannot contain formulas. Only data.
If your process can read and write to Excel it is a much better defined format.
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.
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.
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.
Excel on Mac is another ball of wax though. Bit of a dog, that.
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.
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.
But they couldn't figure it out either so it's limited to data formatted as table.
Following spreadsheets is like trying to find something in my garage if all of the boxes have lids. But if the boxes are all open, I can find stuff in a jiffy, even if the boxes are disorganized.
It 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.
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.
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!
Can you give an example? I am unaware of such power.
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...
In my old job, we had to switch away from our working but ancient Information System to SAP for similar reasons.
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.
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'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.
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.
Um, what then is the point of an auditor?
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.
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.
Answering your edit, not all spreadsheets are opaque either. We design ours to be audited.
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.
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.
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.
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.
> 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?
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.
Now think of 100 pieces of software that you are confident are 100% error free?
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.
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?
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.
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.
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/
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.
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).
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.
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.)
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? :\
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.
At best it’s an arranged marriage, at worst it’s Stockholme syndrome.
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.
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.
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.
Perhaps you could use an alternative differentiator for your data presentation?
I’m morbidly curious to hear more about this scenario.
Still don't know of a single case where the "feature" was useful.
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.
Your primary point is solid. Seconded.
Unfortunately it's rather easy to mistype it as ctrl shift c, which --as you might have guessed-- is "call everyone".
I’ve seen all sorts of gross workarounds. The URL bar is my go to these days, mainly because that works on mobile.
Serifs in increasing somberness for the most concrete numbers, sans for everyday estimates, and papyrus whenever I just toss random numbers in.
As someone with color discrimination problems and contrast difficulties, I would so much prefer font/style coding over color coding. Sounds great!
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 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?
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.
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.
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…)
Thanks, you completed my bingo card.
Doesn't the fact that you can't imagine a single reason why youd want multiple fonts on a spreadsheet alarm you?
Why do I now doubt your assertion?
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.
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.
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.
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).
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.
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?
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.
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
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.
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.
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.
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.
Tables.
https://workspaceupdates.googleblog.com/2024/05/tables-in-go...
Assuming that this relates to checks/cheques, are they going away in the US?
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.
* 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.
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.
Looks like I belong to those people that don't understand: What "payment amounts" are you increasing?
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”.
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.
My example is for people struggling with credit cards and high interest loans that don’t have investment properties.
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.
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.
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.
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!
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")
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.
Can you elaborate please? I don't get your point.
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.
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.
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)
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 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.
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.
It’s ironic that you cite the one thing that being bad at hasn’t held Excel back. ;)
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.
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".
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.
You can test for yourself - try doing some complex operations on large datasets on both. See which one performs better.
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.
No company used Google Workspace. All where Office 365.
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 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.
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.
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).
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.
And, of course, they will use it for AI training, which could be reverse-engineered in the future to extract training data.
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.
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/
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.
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.
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.
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.
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.
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.
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.
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.
https://youtu.be/-gYb5GUs0dM?si=vzOGscnTURqhdyDe
Warning - this video shows Clippy, the very irritating paperclip!
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.
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 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’ve never done anything crazy heavy with it, but functions and stuff work fine for me I guess.
Calc is ok if you want to work with small spreadsheets and don’t care about the occasional bug.
A few important concrete examples would be much more interesting. In fairness, you did somewhat, but I would be interested in some more details.
> 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).
Excel does have more functions but 90% of people don't need those. If you do, you do.
[1]: https://support.apple.com/guide/numbers/autofill-cells-tan0e...
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.
Weird. I've used Calc extensively on Windows and Linux and have never come across this
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.
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 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.
Even today, complex logic in Excel is mostly done through VBA, JavaScript, Python and the like.
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.
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.
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.
Another fun facts, on average people spent 10% of their working life using Excel.
Some companies dont want to learn a new tool
Or pay for a new tool like itglue/bitwarden/keeper
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.
Gratitude and an upvote to the person who can attach a name and citation to the rule.
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.
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.