Excel is one of the most successful pieces of software of all time, so it's an odd choice for a punching bag. Plus, the tone of this article is (unintentionally, I'm sure) off-putting, particularly:
> You know what happens with Excel. Karen from accounting builds a “simple” spreadsheet to track expenses. Six months later, it’s a 47-sheet monster with circular references and VLOOKUP formulas that would make a mathematician weep. The company depends on it, nobody understands it...
It sounds like Karen did a valuable service to the company. She combined a technical skill set with her domain knowledge to create a system that was so successful that the company now depends on it. Cleaning up the technical debt seems like a task that's well worth the cost.
> ...And when it breaks (not if, when), guess who gets called to fix it?
I'm not sure, honestly. It depends on whether you want the fix being done by a resource you consider to be a cost center or a value center. The former will do the cleanup job for bottom dollar. The latter would team up with Karen to amplify the project's impact while cleaning it up.
For these reasons I think your analogy is not effective. I don't disagree with your thesis, though; I prefer code in almost all cases. But that's just me. I know for certain, though, that if I had stock options in that company in this hypothetical scenario I'd rather keep Karen around than whoever fixes the VLOOKUP syntax. And if visual tools are what empowers Karen... well, there you go.
0cf8612b2e1e · 4m ago
I too never get the Excel hate. Without Excel-what do you expect non programmers to do? They sit in front of a computer all day long-would you prefer they use paper? Official IT resources are a joke and will never deliver something so understandable and malleable as Excel. Sure, the official IT app may be done the right way, but it will quickly become outdated as business processes change and the maintenance budget disappears.
taeric · 1h ago
I'm super sympathetic to this. Used to cynically point out that Excel was the most popular "notebook like" interface for computers.
That said, there are a few points against this as a complaint. First, is the incredibly important point that many many tools are people rediscovering pivot tables. There was a fun rant a while back about "your startup is just a pivot table." Hilarious read.
After that, visual workflows are clearly easier for people to understand. Just look at the directions you get with any "self assembled" furniture. Some of that, I'm sure, is to avoid having to translate a lot? Hard not to argue that it is still probably the more effective way to communicate things.
My final caveat is that the symbolic nature of program code is one that is largely lost on people. Specifically, people seem to think the software is independent of the execution environment that is necessary to understand in the language they are using.
diflartle · 1h ago
> There was a fun rant a while back about "your startup is just a pivot table." Hilarious read.
I'd love to read this, but can't seem to find it. Any idea where I could find it at?
Something1234 · 47m ago
I think it’s an outtake from the “You suck at excel talk” by Joel Spoelsky
taeric · 16m ago
I can't find where I thought I read this. I'm assuming I must have seen a transcript of this speech, once? Regardless, I'm fairly confident this is what I was remembering. Thanks!
throwforfeds · 1h ago
In my experience orgs choose these low code tools because good engineers are expensive and many don't fundamentally understand the process of software development.
I've seen business-side product owners complain "why can't you just make it do XYZ this week, Excel can do that" without realizing the application is being built by like three people and if they want the feature roadmap to be on time -- that they themselves planned months ago -- doing something seemingly trivial might be a non-trivial refactor. Trying to keep them focused on the long term is like dealing with a toddler's attention span.
So then they get impatient and the business goes out and buys Salesforce, because it "does everything for cheap", and then they quickly realize if you want to do some non-trivial thing -- which their custom application of course needs to do -- they're shit out of luck or have to buy Marc Benioff a new island.
daft_pink · 1h ago
I feel the real problem with excel is that it’s not reusable.
Otherwise it’s a decent tool, but the fact that you write your code in a cell that is so tied to other cells with non-useful names that it’s impractical to reuse is a reason why it sucks.
Whereas many of these visual worksflow tools at least can export to json and be manipulated programatically in a useful way.
sas224dbm · 11m ago
of course it's re-usable .. most passionate excel jockeys would agree, as long it's their VBA that gets reused
skydhash · 26m ago
Excel is high level assembly. Immediately executable, worthless on other platforms without reverse engineering.
ajcp · 1h ago
I believe the writer is comparing local visual workflow programs against local Excel workbooks, that is: personal productivity tools run on a users local machine. This is a very important distinction.
The value prop of these "Low-Code No-Code" platforms has absolutely 0 to do with the actual "user/developer" experience being better/easier/more powerful and everything to do with the orchestration, inheritability, visibility, management, and security capabilities that these platforms provide. If I have 5 artisanal, bespoke Excel workbooks that my "developer" accountant runs locally to complete a part of a critical business process (and they invariably do) then I have 5 ways my business can come to a grinding halt when any number of things happens to that accountant or their computer. I would take 50 less powerful, rickety RPA workflows that I can at least see in a control room over those 5 Excel workbooks any day of the week.
eawgewag · 22m ago
Yes, absolutely.
The reason why my startup uses Zapier isn't because we prefer to use no-code to orchestrate this specific workflow. It's because it's faster than building out all the webhooks, routers, integrations, tables, etc necessary to make this workflow work, stuff that Zapier already natively supports
nyeah · 1h ago
It would be neat if we could divide programming into (a) software development; (b) other labor-saving automation that's less serious.
When a tool crosses from (b) into (a), we'd have to acknowledge that too. (Or ignore it and invite a blizzard of problems, which are now inexplicable because "it was done".)
Every thinking person already in fact does differentiate between (a) and (b) in their own work. So admitting it out loud and just talking about it may not be the apocalypse that many expect. But ymmv.
wiradikusuma · 1h ago
Weird, my fellow developers usually don't advocate visual tools like Zapier, but instead roll their own solution (non-visual). Which, to be honest, comes with its own problems.
haswell · 58m ago
In a past life, I ran a tools/operations team at a big company for years and later was the product manager for a visual workflow/integration product for a number of years. I've been the IT department trying to manage the crazy things people in the org build, and later worked with hundreds of customers who wanted visual workflow tools for a long list of reasons that have very little to do with what this blog post describes.
I don't think the author understands why these tools exist or why people find them valuable, and there are a number of major issues with their position.
> Excel and visual workflow tools are fundamentally the same: point-and-click interfaces that let people build complex logic without understanding what they’re actually building. Excel uses cells and formulas, visual workflows use boxes and connectors, but the principle is identical. Both promise to make hard things easy.
While I sort of understand the point they're trying to make, I think it's problematic to call these "fundamentally the same" but then compare them on abstract characteristics. By this logic, a car and a bus are fundamentally the same because they both promise to get us from Point A to Point B. This of course misses out on a myriad of reasons cars and busses are quite different in practice.
> Visual workflow tools aren’t succeeding because they’re better, they’re succeeding because we’ve gotten lazy and scared.
These tools are succeeding because:
- They enable teams and individuals to build things they otherwise couldn't without involving central IT or some dev team
- They provide structure and promise to solve a host of operational/management issues associated with keeping an automation running in perpetuity
- They can often be charged to an expense card vs. requiring headcount, existing resource allocation, new budget, etc.
Is the result also a monstrosity? Possibly. But It's a monstrosity that is making something happen that otherwise wouldn't be happening.
And it's possible that the monstrosity will eventually need to be adopted/fixed by a real dev team, but again, that's a team that would never have gotten involved to begin with if someone hadn't built something that now needs to be "fixed". The team doing the fixing sees this as a problem, but the team who built the monstrosity got something built and into production and see it as a win.
It's entirely possible that a "proper" solution built by a dev team would have been superior. But that ultimately doesn't matter if the only way a thing sees the light of day is through the Excel/Visual Workflow Tool pipeline.
These products are not targeted at people who have the ability to build things from scratch the "right" way. And the reasons people/companies buy them usually fall into a few categories: resource constraints, politics, and managers/directors wanting to gain autonomy to build things for their teams without fighting for budget/prioritization with central dev/IT.
> You know what happens with Excel. Karen from accounting builds a “simple” spreadsheet to track expenses. Six months later, it’s a 47-sheet monster with circular references and VLOOKUP formulas that would make a mathematician weep. The company depends on it, nobody understands it...
It sounds like Karen did a valuable service to the company. She combined a technical skill set with her domain knowledge to create a system that was so successful that the company now depends on it. Cleaning up the technical debt seems like a task that's well worth the cost.
> ...And when it breaks (not if, when), guess who gets called to fix it?
I'm not sure, honestly. It depends on whether you want the fix being done by a resource you consider to be a cost center or a value center. The former will do the cleanup job for bottom dollar. The latter would team up with Karen to amplify the project's impact while cleaning it up.
For these reasons I think your analogy is not effective. I don't disagree with your thesis, though; I prefer code in almost all cases. But that's just me. I know for certain, though, that if I had stock options in that company in this hypothetical scenario I'd rather keep Karen around than whoever fixes the VLOOKUP syntax. And if visual tools are what empowers Karen... well, there you go.
That said, there are a few points against this as a complaint. First, is the incredibly important point that many many tools are people rediscovering pivot tables. There was a fun rant a while back about "your startup is just a pivot table." Hilarious read.
After that, visual workflows are clearly easier for people to understand. Just look at the directions you get with any "self assembled" furniture. Some of that, I'm sure, is to avoid having to translate a lot? Hard not to argue that it is still probably the more effective way to communicate things.
My final caveat is that the symbolic nature of program code is one that is largely lost on people. Specifically, people seem to think the software is independent of the execution environment that is necessary to understand in the language they are using.
I'd love to read this, but can't seem to find it. Any idea where I could find it at?
I've seen business-side product owners complain "why can't you just make it do XYZ this week, Excel can do that" without realizing the application is being built by like three people and if they want the feature roadmap to be on time -- that they themselves planned months ago -- doing something seemingly trivial might be a non-trivial refactor. Trying to keep them focused on the long term is like dealing with a toddler's attention span.
So then they get impatient and the business goes out and buys Salesforce, because it "does everything for cheap", and then they quickly realize if you want to do some non-trivial thing -- which their custom application of course needs to do -- they're shit out of luck or have to buy Marc Benioff a new island.
Otherwise it’s a decent tool, but the fact that you write your code in a cell that is so tied to other cells with non-useful names that it’s impractical to reuse is a reason why it sucks.
Whereas many of these visual worksflow tools at least can export to json and be manipulated programatically in a useful way.
The value prop of these "Low-Code No-Code" platforms has absolutely 0 to do with the actual "user/developer" experience being better/easier/more powerful and everything to do with the orchestration, inheritability, visibility, management, and security capabilities that these platforms provide. If I have 5 artisanal, bespoke Excel workbooks that my "developer" accountant runs locally to complete a part of a critical business process (and they invariably do) then I have 5 ways my business can come to a grinding halt when any number of things happens to that accountant or their computer. I would take 50 less powerful, rickety RPA workflows that I can at least see in a control room over those 5 Excel workbooks any day of the week.
The reason why my startup uses Zapier isn't because we prefer to use no-code to orchestrate this specific workflow. It's because it's faster than building out all the webhooks, routers, integrations, tables, etc necessary to make this workflow work, stuff that Zapier already natively supports
When a tool crosses from (b) into (a), we'd have to acknowledge that too. (Or ignore it and invite a blizzard of problems, which are now inexplicable because "it was done".)
Every thinking person already in fact does differentiate between (a) and (b) in their own work. So admitting it out loud and just talking about it may not be the apocalypse that many expect. But ymmv.
I don't think the author understands why these tools exist or why people find them valuable, and there are a number of major issues with their position.
> Excel and visual workflow tools are fundamentally the same: point-and-click interfaces that let people build complex logic without understanding what they’re actually building. Excel uses cells and formulas, visual workflows use boxes and connectors, but the principle is identical. Both promise to make hard things easy.
While I sort of understand the point they're trying to make, I think it's problematic to call these "fundamentally the same" but then compare them on abstract characteristics. By this logic, a car and a bus are fundamentally the same because they both promise to get us from Point A to Point B. This of course misses out on a myriad of reasons cars and busses are quite different in practice.
> Visual workflow tools aren’t succeeding because they’re better, they’re succeeding because we’ve gotten lazy and scared.
These tools are succeeding because:
- They enable teams and individuals to build things they otherwise couldn't without involving central IT or some dev team
- They provide structure and promise to solve a host of operational/management issues associated with keeping an automation running in perpetuity
- They can often be charged to an expense card vs. requiring headcount, existing resource allocation, new budget, etc.
Is the result also a monstrosity? Possibly. But It's a monstrosity that is making something happen that otherwise wouldn't be happening.
And it's possible that the monstrosity will eventually need to be adopted/fixed by a real dev team, but again, that's a team that would never have gotten involved to begin with if someone hadn't built something that now needs to be "fixed". The team doing the fixing sees this as a problem, but the team who built the monstrosity got something built and into production and see it as a win.
It's entirely possible that a "proper" solution built by a dev team would have been superior. But that ultimately doesn't matter if the only way a thing sees the light of day is through the Excel/Visual Workflow Tool pipeline.
These products are not targeted at people who have the ability to build things from scratch the "right" way. And the reasons people/companies buy them usually fall into a few categories: resource constraints, politics, and managers/directors wanting to gain autonomy to build things for their teams without fighting for budget/prioritization with central dev/IT.