Code is a way of explaining rules. If you have a lot of complicated rules, whatever system you use to represent it is going to be complicated. Best case scenario for low code is when the rules are simple or very predictable. In my experience, this is very rarely the case, no matter how simple a problem seems from the outset
I’ve seen this exact thing, a “low code” engineer creates an app, we asked for some changes and all of a sudden “no can’t be done” - it is almost comical tbh
For compilers or anything else, if you have a bunch of spaghetti code, the first step is always to clean up the code. Refactor it to the point where you can easily swap in your low code module. Then determine whether it's still worth it to do so.
What happens all too often is a hack week project that brings in some low code functionality in some simple use case gets shown off and kicks off a bigger effort. But then the edge cases buried in the spaghetti code come up in some way tangential to the low code approach, so it gets hacked in. This happens over and over, and eventually your low code model is just as spaghettified as your code was, except now that spaghetti spans yaml, some interpretation layer, and the remaining two thirds of the original code that you haven't migrated yet.
For this I'll coin my law of declarative intentions: the resulting low code cannot be simpler than well factored code itself.
In my experience, low-code is “easy software development” but without the guard-rails of version control, debugging, open standards, local development, unit-testing etc etc…
These are the things that really matter as software complexity grows…
It's true that most low-code solutions have no version control but that's not because it's not possible, its because no one builds version control as low-code solutions aren't taken seriously. And without a VC, low-code solution won't be taken seriously.
I have been using Node-RED[1] for some time now and have began creating a visual version control concept. The difficulty is differentiating between visual changes and logical changes - visual changes aren't usually the cause of bugs.
[1]="Low-code programming for event-driven applications" - https://nodered.org
