Those low-code tools devs love so much? They'll grow 20% in 2023, says Gartner

The global market for low-code development technologies is set to grow nearly 20 percent from 2022, to reach $26.9 billion in 2023, according to a forecast from Gartner. The IT research firm sees "hyperautomation and composable business initiatives" as drivers accelerating the adoption of low-code technologies between now and …

[elsergiovolador]

Dumbing down

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.

[Graham 32]

Re: Dumbing down

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

[Anonymous Coward]

Re: Dumbing down

"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).

[Anonymous Coward]

Re: Dumbing down

You could try the Apache Camel Karavan, an open-source low-code integration toolkit https://github.com/apache/camel-karavan

[Anonymous Coward]

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.

[Alan Bourke]

And with all of them

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

[45RPM]

Re: And with all of them

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.

[Anonymous Coward]

Re: And with all of them

>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.

[Falmari]

Re: And with all of them

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

[45RPM]

Re: And with all of them

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.

[Anonymous Coward]

Re: And with all of them

Anyone saying "Java removes the need to understand the architecture" probably doesn't understand either Java or computer architecture, or software architecture, or systems architecture. Just 'cos it's got higher level types and a GC doesn't make it fingerpainting, no matter what colour your beard. Try wrangling JVM languages without a decent appreciation for your underlying architecture and you'll produce fucking garbage, same as in any other language. I don't think anyone - greybeard or otherwise - has thought or argued anything else.

[Lil Endian]

...pants-on-head levels...

Wibble!

[Dev_Fit]

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

[Falmari]

4GLs will let you build crap quicker.

@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.

[Caspian Prince]

Code is only the bit in the middle of the job I do

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.

[yetanotheraoc]

We must have missed that memo

"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.

[MOH]

Advertising

Can you please either clearly mark the regular updates on whatever Gartner have "predicted" this week as advertising, or just stop publishing their gibberish.

Or even better, for every "prediction" article you publish, link to an article analysing how accurate their quadrant of nonsense has been over their short/medium/long term predictions.

At least that would provide useful data.

[Lil Endian]

Design

I see a problem along the lines of non-programmers (hobby-level programmers, perhaps) that hack out some Excel VBA. I've seen it a lot in financial arenas in BigCorp. Smart enough people, but the code is convoluted, where a programmer would do the same job in far fewer lines of code. Although it works, as they've not designed the "module" before coding it, when it comes to adding features, the spaghetti monster grows, or has a breakdown. [Date handling in VBA is not their friend! How many different ways?!]

The code isn't documented, either in-source or in any specification docs etc. So when said employee is gone, it's the next lucky punter's good fortune to unravel the work, or, more likely, bin it and start their own pasta revolution.

It's also really common for the person at the desk just opposite to have produced something very similar: similar problem, different approach. (The adage that given n programmers they'll produce n different working solutions.)

Design is paramount. Programming is design, it's not dependant on language selection (or non-language selection in the case of low/no-code). Non-programmers do not design.