This is all about consolidation of power within those big corporations.

They'll create tools, so that you think it will benefit you, because you won't need to hire a specialist to get your idea moving, but rather get someone to click through the solution, like a task to move data from one place to another.

Since over time nobody is going to know how to create such a task from scratch, the businesses will find themselves dependent on big corporations and their infrastructure and mercy.

Then if there will be no demand for such jobs, people will stop trying to get into that field and it will become available to select few that will go through corporate ladder and prove themselves loyal to the big corporation.

The end game? Obtaining means of production. It's like China took over our manufacturing capabilities, these giants will take over the software side and we will become slaves.

If it's any good someone will make an open source equivalent and, being free, it will become the dominant tool.

"Low-code" is a non-programmer graphical approach to making software. Think early 2000's Microsoft buzz about UML -> code... it's that.

I had to look up the term as it's clearly a term used by the non-technical (by design).

Devs don't love them. People who aspire to be devs but lack any practical software engineering skills like them. *Their* bosses love them, bedazzled with bullshit notions of building out centres of excellence and delivery centres staffed with nothing but 24 year old business analysts and offshore clicky-draggy gui warriors conquering the world with robotic bollocks automation.

They're expensive, they're inherently locked into a vendor, they're impossible to test, you can only integrate it with the things the vendor deigns to be worthy. They're suitable for some things, like plugging in your service desk to a workflow management system, or maybe generating alerts for HR to do things when other things happen but that's it.

you will hit the edge cases very quickly and realise it would have been better to do it the non-lowcode way.

Ironically, this is what greybeards have been saying about programming languages like Java (or pretty much anything JVM or similar based) vs languages like C. Java removes the requirement to understand the architecture that you’re developing for - speeding up development time but leading (arguably) to inefficiently written code. But big business appears to love it.

From my perspective, you pick the right tool for the job. Sometimes you need C (or even assembly language), often Java (Scala, Kotlin etc) is absolutely the right answer. And sometimes low code is the way to go - I can think of valid use cases for RAD prototyping, and even in a production environment for ETL orchestration (NiFi anyone?). Even if I don’t understand it.

>Ironically, this is what greybeards have been saying about programming languages like Java (or pretty much anything JVM or similar based) vs languages like C. Java removes the requirement to understand the architecture that you’re developing for

This is tip-top total nonsense that I don't anyone has said with a straight face in three decades. Comparing JVM-based programming to something like ServiceNow RPA is just pants-on-head levels of removed from reality.

I agree using that logic, assembler how better to understand the architecture? Binary! ;)

I think that nuance is handled by the use of the term ‘greybeards’, the use of the past tense, and the acknowledgement that tools like Java often are the right answer.

There is no comparison between the tools themselves - only between the styles of argument.

"Devs don't love them" - I'm 100% sure the Reg headline writers were being sarcastic

@AC "Devs don't love them. People who aspire to be devs but lack any practical software engineering skills like them"

I don't entirely agree. As a dev I would not say I love them but I certainly don't hate them. While not 4GL, writing programs for Windows using Visual Studio a lot of basic template code is generated for you if you want it to. C++ with MFC (Document View model) creates the basic SDI or MDI application, C# does similar. A lot of basic front end GUI work is done very much like a 4GL and yes I do love that, it save me having to write GUI handling code, while I concentrate on writing the application code.

I whole heartedly agree with your point lack any practical software engineering skills . 4GLs even though they are at a higher level of abstraction, still require software engineering skills to design the logic and flow of the program. Otherwise the result is a badly built application, that will be slow and buggy. Because the logic has not been thought through.

4GLs just like lower level languages will let you build an application that's a complete pile of crap, just 4GLs let you build that crap quicker.

Low code sounds all very useful until managers realise that the coding part is just the fiddly bit in the middle of what we do for a living as software developers. A significantly large proportion of our time is just understanding what the hell they actually want to something to do. Another rather significantly large proportion of time goes on making sure what got made actually does match up, in reality, with what they wanted it to do in the first place, as well as generally not exploding, falling over, producing strange results when there's an R in the month, etc.

"It's probably the biggest misconception that low code is going for the jobs of developers. It's not about replacing en masse all these different jobs but rescaling and retraining your employees."

I call BS. That's not the biggest *mis*conception. That's the biggest *correct* conception.

Here at $bigcorp, there is a huge push for low code and automation, but the business users are only allowed to push the buttons. To _create_ the buttons you need to send a request to an external team of new hires who have been "trained" on the low code tool. It's the worst of all possible worlds. Whereas before you had to send your request to a dev team that didn't know anything about the business but at least knew their trade, now you send your request to a dev team that doesn't know anything about the business and doesn't have a prayer of getting the stupid tool to do anything beyond the basics.

The article mentioned Apex. We had Apex when it was the new shiny, but it was the same issue. It may be low code compared to a from-scratch custom db application, but with a corporate-mandated development model divorced from the end users it went nowhere. They built a few things with Apex, there were two types. (1) An insanely complex thing that shouldn't have been built in Apex, where the devs spent all their time fighting with Apex to get it to fulfill the business requirements. (2) A trivial app that was completely suitable for Apex, *however* once running you could never get any changes made: "It's working now, we have no time for change requests because we are spending all our time on (1)."

I got all excited when they recently showed us an Apex-alike "low code" tool, backed by a database (not Oracle, so much the better). That would have so many uses in my line of business. Then they explained that the end users only get to push buttons, there is a team that does the development. Worse, they are only interested in doing "big" applications. Same mistake they made with Apex, taking on type-1 anti-solutions. Oh well, at least they learned from Apex that they won't have time for the type-2 solutions, so they are just saying "no" up-front.

Long story short, despite the rhetoric there is no interest in empowering the business user with accessible tools. Quite the opposite, the business user is mandated to be a passive _consumer_ of tech. The low code push is all about saving money by not having to pay skilled devs to use complex tools.