Every time I hear about no code, I think about the code written by PROFESSIONALS that leads to list like Dan Luu's "Everything is broken": https://danluu.com/everything-is-broken/

If professional at top quality firms with the best tools can't write code that works, how is "no code" written by people that don't understand going to work better?

No-code is more likely to be written by people who are direct experts in the business domain, unlike the telephone game that is the development cycle in most software orgs.

I work with experts in the business domain, often C-Suite as a consultant. I've come to understand the domains almost as well as them for the companies I work with. While this knowledge is invaluable, and critical to getting the solution right in my experience they still would be completely lost when it comes to a no-code solution.

They generally only think happy path and have a really hard time understanding why you need to think about edge cases. They don't understand how to structure data or implement robust processes.

No code is great for very simple things. Fill out a form and send it in an email. But for more important and complex things we'll still need programmers. I'm not yet convinced that no-code is an amplifier for programmers. Beginners maybe, but more experienced developers are in my opinion far more likely to be productive in a text based environment.

"No-code" programs are still programs; each visual node or block or whatever is isomorphic to a construct in some programming language. Being code, it has to be maintained, especially as business needs shift, and "experts in the business domain" have other, better things to do with their time than maintain a bunch of computer programs. Thankfully, there are people in the company who specialize in maintaining computer programs -- software engineers. Which means that ultimately, software engineers will be responsible for all that no-code, and in addition to the usual telephone game they must contend with rat-wrestling some near-undebuggable node graph that lives only in a proprietary tool into doing what they want rather than using the tools they're familiar with and best at (ordinary textual code, version control, debuggers, etc.). And, Syndrome style, the company ends up throwing away the valuable time and effort of real software engineers so some mid-level manager can pretend to be one (and walk away when they get bored of that).

This never happens. It just gets written by different professionals. Best case, they are cheaper.

So basically no-code can be used as a foot in the door strategy? Like, hello I offer you some training for this great no-code tool and help you build exactly what you want, then I stick around to round the unavoidable rough edges?

The problem is if you started with no code, can you round the rough edges? One reason we use code instead of no code is so we can extend the product in any direction that is necessary, not just the few that were anticipated by a tool.

Many are impressed by the no-code claims and start that way only to get bitten after a few minor successes by said rough edge - then what else can you do than try to soften your current investment's thorns. And arguably anything can be addressed, given the right motivation/time/money.

My last few jobs have been replacing no-code setups. It certainly doesn't take teams long to figure out how bad the current offering suck. Sometimes only 3-4 integrations in.

There's a lot of people who have been doing the no code thing to build solutions for at least a decade now not knowing a lick of how to write code yet still building fantastic websites that get hacked almost every time because they don't appreciate how to maintain them. Do I need to name names?