[redleggedfrog]

I'm frequently on that receiving end of low-code implementations that have failed, and I'm not quite as fond of it as you. ;^)

The problem is reasoning. Often the low code limitations funnels the implementation into a contorted state, so by the time they've decide to give up what I get is frequently exceptionally difficult to comprehend. Usually I peek at it, try to get an idea, and then do what I would have done if assigned to task from the get-go - read (or make) a spec, and go from there. I'm doing some quick napkin calculations from the time tracking system, and the ratio is approximately 13/2 on the last 7 of these no-code to code tasks. What they attempt in no-code in 13 hours and fail I finish in, yes, 2. Given, these are not developers, and sometimes these actually come from the CEO (who does not track their time so they're not in that ratio), but mostly they're just managers and remote hires. And I've been developing software for 28 years now, so I have some capability. Also, these are mainly data related projects, so maybe other types of work would have more success.

No code will get better, I'm sure, but the problems we're solving actually are getting harder (it seems to me) and reasoning about them is the difficult part. I'm not sure how to no-code that.

[tabtab]

"Those who don't know history are doomed to repeat it." I haven't seen any "low-code" tool with technology and ideas noticeably beyond what such tools tried in the 90's. If there were some kind of breakthrough that gave such tools something earlier tries didn't have, then maybe it would be time to take a new look. But until then, I'll remain skeptical. Remember Steve Balmer's smarter brother: "Maintenance, maintenance, maintenance!" (hypothetical brother)