Every visual workflow tool is just Excel for developers who gave up(medium.com)
medium.com
Every visual workflow tool is just Excel for developers who gave up
https://medium.com/@mohamedalibenothmen1/every-visual-workflow-tool-is-just-excel-for-developers-who-gave-up-f7261090fbc8
66 comments
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.
I mean I hate Excel - for me. Not for anyone else. I think it is a great piece of software and I only wish I could make something as successful. But I definitely hate working with it.
Thank you so much for this thoughtful comment. I want to start by sincerely apologizing if the analogy came off as dismissive or disrespectful. I didn't mean to diminish from excel at all, in fact, you've highlighted exactly why Excel is so powerful and why my analogy works, just not in the way I originally framed it.
Let me clarify what I was trying to get at: Excel's success comes from empowering domain experts like Karen to solve real problems without needing a computer science degree. That's genuinely amazing and valuable. The "problem" isn't Excel itself or Karen's contribution, it's when the tool becomes the permanent solution rather than a stepping stone.
My point about visual workflow tools was similar: they're incredibly powerful for rapid prototyping and getting things done quickly. But when professional developers (whose core skill is writing maintainable, scalable code) use them as their primary solution, we might be missing opportunities for more robust, long-term approaches.
You're spot on about the value vs. cost center perspective. In Karen's case, the smart move is absolutely to work WITH her domain expertise while adding technical structure. Similarly, visual workflow tools can be fantastic for proof-of-concept or when you need something working yesterday.
I think my tone came across as dismissive when I meant to be more reflective about when we choose the right tool for the job. Thanks for pushing back on this, it's made me think more carefully about how I frame these discussions. Both Excel and visual workflow tools have earned their success for good reasons.
Genuinely very curious: are you finding that meaningful numbers of experienced developers are turning to these visual workflow tools instead of writing code for substantial use cases?
I was a bit confused by the post because it seems to be written about a persona that I haven't personally come across: professional developers who choose visual workflow tools as a primary solution over building with code the "right way".
I'm still a bit confused because you make broad statements about these tools and their users while actually you seem to be focused on this specific subset of users. e.g. when you talk about why these tools are successful, was your intent to limit the scope of your comments about the success of this category to just professional developers?
In a separate comment, I criticized the post before I fully realized you're specifically talking about developers, and not the typical audience for these products. I'm trying to understand if that's the lens through which the entire post should be interpreted. If so, making that more clear would strengthen the post I think.
I'm still a bit skeptical about the existence of said persona, but happy to be shown I'm wrong.
I was a bit confused by the post because it seems to be written about a persona that I haven't personally come across: professional developers who choose visual workflow tools as a primary solution over building with code the "right way".
I'm still a bit confused because you make broad statements about these tools and their users while actually you seem to be focused on this specific subset of users. e.g. when you talk about why these tools are successful, was your intent to limit the scope of your comments about the success of this category to just professional developers?
In a separate comment, I criticized the post before I fully realized you're specifically talking about developers, and not the typical audience for these products. I'm trying to understand if that's the lens through which the entire post should be interpreted. If so, making that more clear would strengthen the post I think.
I'm still a bit skeptical about the existence of said persona, but happy to be shown I'm wrong.
That's a really fair question, and you're right that I could have been clearer about the persona I'm addressing.
I'm actually part of that audience myself! As a developer and automation enthusiast, I fell in love with tools like Zapier and n8n, they're genuinely great for getting things done quickly. I still use them today for certain use cases.
But here's where I've noticed the pattern: I've seen experienced developers (myself included) increasingly reaching for these visual tools even for complex workflows where code would be more appropriate. The tipping point for me was when I found myself building workflows that required custom scripts within the visual tools, dealing with 3-5 second execution times, and accepting limitations that I could easily solve with a few lines of code.
You're absolutely right that the typical audience for these products isn't professional developers and it's business users, which is exactly why these tools are so successful and valuable. My frustration (and the motivation for this post) comes from seeing developers including myself choose the visual approach when we have better alternatives.
This experience actually led me to build a code-first workflow automation engine with Bun and Rust that can handle computational-heavy workflows in milliseconds rather than seconds, at a fraction of the cost. I can even run it in a 1vcpu, 1GB ram VPS and still get a great performance.
I think you've highlighted exactly why the post felt off, I was conflating the general success of these tools (which is well-deserved for their target audience) with a specific developer behavior that perhaps isn't as widespread as my bubble made it seem. Thanks for pushing me to clarify that distinction.
I think I might have phrased my criticism too sharply, sorry about that. I wouldn’t have commented if I didn’t think you were making a worthy point though! There was an article about malleable software recently that used avocado slicers vs. kitchen knives as an analogy; the more I think about your piece, the more it resembles that concept.
https://www.inkandswitch.com/essay/malleable-software/
https://www.inkandswitch.com/essay/malleable-software/
No need to apologize at all. I really appreciate you taking the time to engage thoughtfully! Your feedback helped me clarify my own thinking, which is exactly the kind of conversation I love.
And that avocado slicer vs. kitchen knife analogy is perfect, it captures the nuance so well. Some tools are brilliantly specialized, while others thrive on flexibility. Maybe the real takeaway is that knowing when to reach for each is the mark of a savvy developer.
Thanks again for the great discussion, this is why I love sharing on Hackernews, nowhere else has such a density of curious, sharp-minded people who push ideas further.
And that avocado slicer vs. kitchen knife analogy is perfect, it captures the nuance so well. Some tools are brilliantly specialized, while others thrive on flexibility. Maybe the real takeaway is that knowing when to reach for each is the mark of a savvy developer.
Thanks again for the great discussion, this is why I love sharing on Hackernews, nowhere else has such a density of curious, sharp-minded people who push ideas further.
> 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.
The technical debt here was solved by creating a complex Excel worksheet. The sheet is the solution.
For small companies where these Excel monsters get created, it is the #1 best way (read - cheapest) to solve technical debt, which, before Excel, was probably a bunch of arcane manual processes that took 5x as long with worse accuracy.
The technical debt here was solved by creating a complex Excel worksheet. The sheet is the solution.
For small companies where these Excel monsters get created, it is the #1 best way (read - cheapest) to solve technical debt, which, before Excel, was probably a bunch of arcane manual processes that took 5x as long with worse accuracy.
Thank you for your comment.Totally get what you’re saying and yeah, that’s a solid take. My main point was more about what happens next when those "Excel-as-solution" systems grow beyond their original scope and start needing maintenance, collaboration, or scale. That’s where things can get tricky. But I completely agree Excel often is the hero in the early stages.
Good point, though not all spreadsheets are created equal. Some get quite unmanageable, and that can be a productivity bottleneck over time (unless you're not really adding new use cases)
Maybe the real problem to solve is not killing Excel but providing a pathway for load-bearing Excel sheets to grow into full applications, development practices and all.
I think the hardest part here is UI.
With Excel you get no-code immediate UI feedback in the cells.
Most people will use an Excel sheet as an array or a dataframe.
With Excel you get no-code immediate UI feedback in the cells.
Most people will use an Excel sheet as an array or a dataframe.
I feel like this is doable with a good LLM-assisted coding tool, but it's just a hunch.
>> ...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.
You're right that the answer is "it depends." In the world of risk management and audit, what Karen has created is called a "user-developed application." Her employer should give her a big pat on the back, and then take a step back to decide 1) if this Excel spreadsheet is mission critical, 2) if it is, who will maintain it, and 3) whether its importance justifies building a formal IT solution to support the business function (either in-house or using COTS software).
I agree that Karen did nothing wrong! She found a process that could be improved or automated, and was able to use technology to do it. If someone is caught off guard when the Excel file goes kaput, then that's not Karen's problem nor is it her fault; it's her employer's responsibility to pay attention to their own business requirements.
>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.
You're right that the answer is "it depends." In the world of risk management and audit, what Karen has created is called a "user-developed application." Her employer should give her a big pat on the back, and then take a step back to decide 1) if this Excel spreadsheet is mission critical, 2) if it is, who will maintain it, and 3) whether its importance justifies building a formal IT solution to support the business function (either in-house or using COTS software).
I agree that Karen did nothing wrong! She found a process that could be improved or automated, and was able to use technology to do it. If someone is caught off guard when the Excel file goes kaput, then that's not Karen's problem nor is it her fault; it's her employer's responsibility to pay attention to their own business requirements.
"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."
This is not the first time I see developers berating non-technical users, and I like the thesis that they will function as cost-centers that will do a cleanup job instead of teaming up with the user. It's like they will attempt to "do the work" in a binary fashion, making the "correct" choices, often focused on technical factors, like which library to use or what algorithm, instead of focusing on the business domain.
I also see this attitude when facing technical issues or bad code as if it wasn't our job to deal with bad code (and as if non-bad code existed)
This is not the first time I see developers berating non-technical users, and I like the thesis that they will function as cost-centers that will do a cleanup job instead of teaming up with the user. It's like they will attempt to "do the work" in a binary fashion, making the "correct" choices, often focused on technical factors, like which library to use or what algorithm, instead of focusing on the business domain.
I also see this attitude when facing technical issues or bad code as if it wasn't our job to deal with bad code (and as if non-bad code existed)
> Excel is one of the most successful pieces of software of all time
This is constantly repeated truisms, and yet I don't use it and have no plans using it. I'm certain I'm not alone. Excel is counterintuitive and not 'consumable' as the opposite to SQLite. Surely I understand it not the same. Also I suspect most of the Excel users use it like CVS editor.
This is constantly repeated truisms, and yet I don't use it and have no plans using it. I'm certain I'm not alone. Excel is counterintuitive and not 'consumable' as the opposite to SQLite. Surely I understand it not the same. Also I suspect most of the Excel users use it like CVS editor.
Anyone who hasn't used Excel is totally out of touch with reality (constrained to developed world). Excel is counterintuitive to whom? What intuition does it upset? It's a grid of cells. Each cell
can reference any other. You can immediately see the definition of any cell when selecting it. I'd wager that it's used as a presentation or modeling tool far more than as a CSV editor. Its dynamic aggregated views, what-if scenarios, charting and dashboarding hardly could be replicated with SQLite or CSV tools alone. Surely not as seamlessly or intuitively as Excel.
Agreed, it has permeated every single industry in the developed world. Professional software developers have been known to reach for it, in a pinch, over dozens of other known and much more powerful tools.
The immediate feedback and visual layout make it the definition of "killer app." Jupiter notebooks has been trying to replicate the magic for years. Entire businesses and industries are built around selling products to successfully replicate what was originally living in a spreadsheet somewhere.
The immediate feedback and visual layout make it the definition of "killer app." Jupiter notebooks has been trying to replicate the magic for years. Entire businesses and industries are built around selling products to successfully replicate what was originally living in a spreadsheet somewhere.
> I don't use it and have no plans using it. I'm certain I'm not alone.
Too easy to refute. Treating "Excel" as actually "spreadsheet processing," the software has been so consistently and hugely popular that everything from early PDAs [0] to Google Sheets / iCloud Numbers has supported it. Every type of personal computing device has it, from graphic calculators [1] to laptops to tablets to PDAs to many cell phones.
> I suspect most of the Excel users use it like CVS editor.
Like some classes of addictive chemical compounds, you may start with this but quickly find it is the gateway to other habits.
[0] https://en.wikipedia.org/wiki/HP_95LX
[1] https://education.ti.com/en/software/details/en/139B977E62CB...
Too easy to refute. Treating "Excel" as actually "spreadsheet processing," the software has been so consistently and hugely popular that everything from early PDAs [0] to Google Sheets / iCloud Numbers has supported it. Every type of personal computing device has it, from graphic calculators [1] to laptops to tablets to PDAs to many cell phones.
> I suspect most of the Excel users use it like CVS editor.
Like some classes of addictive chemical compounds, you may start with this but quickly find it is the gateway to other habits.
[0] https://en.wikipedia.org/wiki/HP_95LX
[1] https://education.ti.com/en/software/details/en/139B977E62CB...
Tell me what other piece of software gives so much turing-complete power to non-technical users.
"Karen" can literally write programs with little training, there's memory, there's functions, there's references, excel is the best.
"Karen" can literally write programs with little training, there's memory, there's functions, there's references, excel is the best.
Problem arises when "Karen" leaves the company. Then the company asks the "IT guy" to "help" with that Excel sheet on a shared. Again, as I highlighted Excel sheets is not a 'consumable' software. OK to use for one time things, but in a long run it's most likely a mistake.
We never ever see this scenario happen with code :-)
Famously Jane's Street started by using excel automation for its core trading business.
I do not particularly like excel, I find it interesting but often obtuse and limited in annoying ways and I agree that for an established workflow using "proper" code is generally better. But imho where Excel excels is in dynamic exploration and supporting decision making, where the type of analysis and visualisations you might want to do can change radically and quickly
I do not particularly like excel, I find it interesting but often obtuse and limited in annoying ways and I agree that for an established workflow using "proper" code is generally better. But imho where Excel excels is in dynamic exploration and supporting decision making, where the type of analysis and visualisations you might want to do can change radically and quickly
I don't see how that matters. XYZ can still be the most successfulest even if you don't use it. Even if 1,000,000 people don't use it.
I feel like I'm hearing "Hundreds of people who don't like Elvis can't be wrong". And I don't even like Elvis!
I feel like I'm hearing "Hundreds of people who don't like Elvis can't be wrong". And I don't even like Elvis!
> Excel is one of the most successful pieces of software of all time, so it's an odd choice for a punching bag.
So is Photoshop and Google Maps - the point of the article isn't bashing on Excel, it's about choosing the wrong tool for a job.
So is Photoshop and Google Maps - the point of the article isn't bashing on Excel, it's about choosing the wrong tool for a job.
The real problem is that even though most problems are actually text problems (or can be represented by text chars) we don't have version control with the same level of granularity for spreadsheets.
Really? What's a database? A spreadsheet. Databases can have version control, backups, etc.
And, what's git? A spreadsheet can be committed to git.
Version control for spreadsheets? It'd be awesome to have on its own, but it's also not hard to add it on top of spreadsheets' existing features.
And, what's git? A spreadsheet can be committed to git.
Version control for spreadsheets? It'd be awesome to have on its own, but it's also not hard to add it on top of spreadsheets' existing features.
It is often said that xlsx and docx files are basically zipped folders of XML files and assets, I wonder how effective it would be to add the decompressed forms to git to see and track changes (or similarly for git to show diffs for the files inside a tar/zip
Not hard at all as it turns out. I had to do this a few years back to extract PBI metadata (metric names, queries, data sources, etc.) from of our dashboards.
I hope you realize you aren't disagreeing with me.
That's exactly my point.
It's always interesting to see where developers don't build obvious solutions into existing tool.
You're very right that it's not hard, but to me, the fact it hasn't been done, is interesting thing from a sociological perspective.
I've seen many code editors with amazing git ergonomics built in, never for spreadsheets.
I'm actually working on text only spreadsheet markup that is human intuitive and building interfaces to go with it.
That's exactly my point.
It's always interesting to see where developers don't build obvious solutions into existing tool.
You're very right that it's not hard, but to me, the fact it hasn't been done, is interesting thing from a sociological perspective.
I've seen many code editors with amazing git ergonomics built in, never for spreadsheets.
I'm actually working on text only spreadsheet markup that is human intuitive and building interfaces to go with it.
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.
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.
> 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?
I'd love to read this, but can't seem to find it. Any idea where I could find it at?
I think it’s an outtake from the “You suck at excel talk” by Joel Spoelsky
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!
If anything we need more Excels. Excel is coding for people who don't even know they're coding.
Karen from accounting made an entire app even though she's not a "software developer" by trade and people think that's a bad thing?
Karen from accounting made an entire app even though she's not a "software developer" by trade and people think that's a bad thing?
I also agree with your sentiment.
Excel is coding for people who are not programmers.
But I think the author conflates 1) engineering practices
2) Programming
3) Expressing domain knowledge using tables, charts and numbers
Most excel users do 3) They are certainly not programmers, and the do not follow engineering practices we associated with programming: modularity, hiearchical or functional re-usability, testability, etc
Excel creators do not reproduce bug reports, do not measure their success by the number of bugs they fixed, they do not do SDLC...
These are not particularly fault of excel. But as soon as there is a recognition that 'oh that excel workbook needs to be managed by programmers' -- then after a few month programmers realize that Excel and VBA macros are subpar programming environment, and will just argue that the way that the author does -- that it does not make sense to maintain a complex, business critical code within Excel.
So they will re-write it in Python or something else.
---
I think Ex cell's success in the business world is precisely because it allows non-programmers to bypass the whole SDLC and express their domain knowledge in a computational system.
As programmers, we want to replace Excel with something that
a) allows business users to do what they want to do, without SDLC
b) when their work reaches a certain level of complexity, we want the tool to allow us to gradually transition the work the domain users have done into an engineered piece of software with minimal effort, free of cost, easy to debug.
I do not think such as system exists yet, but that would be a killer app
But I think the author conflates 1) engineering practices
2) Programming
3) Expressing domain knowledge using tables, charts and numbers
Most excel users do 3) They are certainly not programmers, and the do not follow engineering practices we associated with programming: modularity, hiearchical or functional re-usability, testability, etc
Excel creators do not reproduce bug reports, do not measure their success by the number of bugs they fixed, they do not do SDLC...
These are not particularly fault of excel. But as soon as there is a recognition that 'oh that excel workbook needs to be managed by programmers' -- then after a few month programmers realize that Excel and VBA macros are subpar programming environment, and will just argue that the way that the author does -- that it does not make sense to maintain a complex, business critical code within Excel.
So they will re-write it in Python or something else.
---
I think Ex cell's success in the business world is precisely because it allows non-programmers to bypass the whole SDLC and express their domain knowledge in a computational system.
As programmers, we want to replace Excel with something that
a) allows business users to do what they want to do, without SDLC
b) when their work reaches a certain level of complexity, we want the tool to allow us to gradually transition the work the domain users have done into an engineered piece of software with minimal effort, free of cost, easy to debug.
I do not think such as system exists yet, but that would be a killer app
Totally agree. Excel is incredibly powerful, and people like Karen are doing real development, whether they realize it or not. My point wasn’t that Excel (or visual tools) are bad, it’s that when systems grow in complexity, they eventually need the same discipline, clarity, and maintainability that code provides. And that’s where things can get messy if we’re not careful.
Yeah, isn't the main user of those tools non-developers? It's not that developers are getting lazy, it's that people who aren't developers also have technical needs (and some chops).
Not all reasonable-sounding developer complaints are legitimate business complaints. For example technical debt is bad, but there are much worse scenarios. For example consider "no customer."
(Not picking on developers in particular. Similar story applies to salespeople, lawyers, technicians, scientists, accountants, or anybody else.)
(Not picking on developers in particular. Similar story applies to salespeople, lawyers, technicians, scientists, accountants, or anybody else.)
More excels and more improvements to debugging excel please (:
The real super power to excel is you can see the data as it flows through the cells. Whenever I see a visual programming tool that is just a way to write a regular script by linking up a DAG I can't help but feel like they missed the point. Motivated non-programmers have been using COUNTIF, VLOOKUP and such since forever. They're not incapable of writing a textual program 1 statement at a time, it's just that most programming environments don't facilitate it.
The real super power to excel is you can see the data as it flows through the cells. Whenever I see a visual programming tool that is just a way to write a regular script by linking up a DAG I can't help but feel like they missed the point. Motivated non-programmers have been using COUNTIF, VLOOKUP and such since forever. They're not incapable of writing a textual program 1 statement at a time, it's just that most programming environments don't facilitate it.
In this spirit excel would be way easier to debug if you could easily show the value of subexpressions in complex formulas
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.
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.
Yup, but this time its their choice that one upped the supposed experts, so they cling to buying Marc island for at least 5 years.
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.
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.
Excel is high level assembly. Immediately executable, worthless on other platforms without reverse engineering.
I don't mean reusing excel formulas on other platforms.
I mean if you write a really long formula in a cell, it's not really practical to use that formula in another workbook that doesn't have the exact same structure.
If you compare that to say a Jupyter notebook which is cell based, you can at least reuse your function in another notebook or cell within any other jupyter notebook rapidly and quickly if you wrote it correctly. Excel not so much.
I mean if you write a really long formula in a cell, it's not really practical to use that formula in another workbook that doesn't have the exact same structure.
If you compare that to say a Jupyter notebook which is cell based, you can at least reuse your function in another notebook or cell within any other jupyter notebook rapidly and quickly if you wrote it correctly. Excel not so much.
You can have named ranges and cells in Excel, and Excel even has lambda/anonymous functions now. So in latest editions of excel functions can be as general or brittle as they are in any other language or environment, it just depends on how they're written.
of course it's re-usable .. most passionate excel jockeys would agree, as long it's their VBA that gets reused
In every project I’ve seen where someone has evangelized a visual workflow designer (bar none), the overriding argument has been that “power users”, can “manage” the business workflows.
In every project the business users have no interest in “managing” business workflows, so the developers that built the tool end up having to use the tool for them, implementing their business use cases.
Developers are much more comfortable with code. You cannot easily unit test visual workflow designers. You cannot easily version or put visual workflow designs into source control.
Whenever I see one of these projects I run screaming in the opposite direction.
Locode in general is an anti pattern. I’m specifically looking at Microsoft Dynamics and Power Apps, aka. Microsoft Access Online
I would like to be able to upvote this post 100 times.
In every project the business users have no interest in “managing” business workflows, so the developers that built the tool end up having to use the tool for them, implementing their business use cases.
Developers are much more comfortable with code. You cannot easily unit test visual workflow designers. You cannot easily version or put visual workflow designs into source control.
Whenever I see one of these projects I run screaming in the opposite direction.
Locode in general is an anti pattern. I’m specifically looking at Microsoft Dynamics and Power Apps, aka. Microsoft Access Online
I would like to be able to upvote this post 100 times.
Absolutely agree! I’ve seen the same thing happen. The idea that “power users” will manage workflows sounds great on paper, but in reality, it always falls back on developers. And once things get even slightly complex, I end up writing custom scripts anyway because the visual tools just can’t handle it cleanly.
At that point, you’re stuck using a tool that’s harder to debug, test, or version and still coding on the side. Totally with you on this being an anti-pattern in most serious use cases.
At that point, you’re stuck using a tool that’s harder to debug, test, or version and still coding on the side. Totally with you on this being an anti-pattern in most serious use cases.
I agree that devs (and everyone else) are fundamentally lazy. I don't agree with the scared. People would rather spend time on things that bring them joy, and that thing which made them excited to work with Company X might be no more, or a whole other thing altogether, 6 months later. But they still need that paycheck, so they do what they can to offset the increasing pain and displeasure so they can continue.
The characterization of visual workflow tools is also an incidental affair: there are commercial tools, and there are open source tools. Just depends on the kind of support one wants, and many devs would love some decent support when some component breaks or something's missing, hence the more likely adoption of a commercial solution.
And in the end it's also just the next evolution of software development tools that's being sought. We moved from flipping switches, to boxes of punch cards, to Assembly, to C-like, to Python-like. We're looking for the next form, and 2-D node-like programming does seem an improvement over 1-D text, as text was an improvement over reams of punched paper. And there will always be those who continue to enjoy doing Assembly, even though the majority moved on to higher level languages, which will also be the case for the current and next level tools.
The characterization of visual workflow tools is also an incidental affair: there are commercial tools, and there are open source tools. Just depends on the kind of support one wants, and many devs would love some decent support when some component breaks or something's missing, hence the more likely adoption of a commercial solution.
And in the end it's also just the next evolution of software development tools that's being sought. We moved from flipping switches, to boxes of punch cards, to Assembly, to C-like, to Python-like. We're looking for the next form, and 2-D node-like programming does seem an improvement over 1-D text, as text was an improvement over reams of punched paper. And there will always be those who continue to enjoy doing Assembly, even though the majority moved on to higher level languages, which will also be the case for the current and next level tools.
[deleted]
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.
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.
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
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
I would highly recommend looking into n8n if you're digging Zapier.
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.
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.
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.
A notable exception is MS Access. It was a huge productivity win. It did not work well with version control but otherwise, it let developers rapidly develop and maintain moderate sized solutions to common business problems. It was also extensible with plain text code when needed.
This article is missing something important: businesses are adopting these services in order to lower the required skill level of their headcount roles. If they can outsource the work to a worse product that is barely fit for purposes while reducing the pay and tier of the headcount associated with maintaining it, then that’s a total win so long as flexibility and resilience are lower priority than increasing profits by replacing a high-skilled programmer with a low-skilled worker.
One place where Visual development tools almost always win is in problem domains that are intrinsically visual (think CAD, form designers, etc)
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.
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.
Excel is probably the only software I consider “perfect” and that is saying a lot imo.
You can brute force via visual workflow tools and it will look impressive to your coworkers because of all the noodles. It's performative like all the shit people did in excel in the 90s.
This is a bit like getting mad that Adam Sandler made another movie. It costs you nothing that stuff other people like exists. Don't waste energy on it.
With AI, this is about to get a whole lot worse.
> 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.