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.
I wonder if it's because some of those at the mid-to-level making these decisions are under the same market pressures as the rest of us to show they've actually 'done sometime' - so they can slap this on a resume and prepare it for an interview when they roll out of the org in a year or two after implementation. This seemed to be the history in the IT department at the hospital I worked out where they had a decade of zombie projects that sorta worked because they were implemented, barely supported, and the persons that made the decision had bounced to something else, leaving IT holding the bag.
Definitely true. Also don't discount the influence of good old fashioned corruption - cash kickbacks, job promises, gifts, etc., I've seen IT contracting decisions so dumb that graft is far and away the most logical explanation.