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.