No, no. Go right ahead and sink time and money into this sort of crap. Just like every attempt before, it'll generate a pile of garbage that's unmaintainable yet will still manage to poop out ONE single nugget of value: determining what needs to be built after the idiot suits thrashed all around with the 'wonder toy' system. Then, we experienced developers can have a walk in the park while cashing out on contracting rates. Fat stacks of cash simply for replacing exact like-for-like functionality with REAL software and then bring in the extensions the vendor toy systems couldn't. I could do with a nice, easy, early retirement path to pop up in 7 years. Bring it on ;)
redleggedfrog|3 years ago
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|3 years ago
JBlue42|3 years ago
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.
rustybelt|3 years ago
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.
rmnclmnt|3 years ago
yrgulation|3 years ago