I've seen "low code" and "no code" solutions running at huge enterprises and it always inevitably ends up resembling a house of cards.
Proponents often cite how much quicker they can ship things and how it lets users define and automate their own workflows without waiting for engineers. The reality is that these time savings come by cutting corners from the development cycle. Because you're not doing "code", the code review step gets skipped. The authoring of automated test suites get skipped. The authoring of performance regression testing gets skipped. There's no waiting for things to bake in non-prod environments because people are changing settings directly on prod. No ones doing phased deployments with automated rollbacks here in these low code and no code environments. No design reviews mean you get solutions that are the absolute worst hacks.. Why go through the work of making "priority" a first class property on your ticket type when you can just string scan for "high" | "medium" | "low" on case titles when doing assignments?
Engineering teams could also move fast if they just threw maintainability to the wind. There's a reason they don't. If you do things the right way in these low/no code environments, the complexity is even worse, because the features are so half-baked that you can't setup proper safeguards without doing crazy amounts of escape-hatches.
From a coding perspective taking over these houses of cards are my favorite kind of project. If the spreadsheet (or whatever) is used to build a system that people start relying upon then the proof of concept is already done, the underlying domain model is fleshed out and the task prioritization is obvious.
Greenfield projects where requirements are vague, priorities are vague, the underlying domain model is vague and the need for the project to exist at all is dubious bug the shit out of me.
One of the most successful companies I ever worked at kickstarted many new business processes with a few guys importing, munging and exporting data from a spreadsheet and sending emails. It was manual and often repetitive. But, all the iteration happened in the background until they nailed down what was needed and then came to me with a set of crystal clear, validated requirements.
It was quite a contrast to all of those other companies where I was given a feature to write that took a week to knock out because a powerful customer said it would be cool to have. Inevitably, even they only played with it for 5 minutes before never using it again and nobody else even touched it once.
Or the other companies that went to the other extreme and treated random excel spreadsheets as fully fledged production systems that would trigger catastrophe if you looked at them funny.
I can't help but feel that there's a sweet spot somewhere here that most people (& low code companies) miss.
I been at one very large enterprise for the last 15 years; the amount of low/no code apps I've been through is...well you know when neo is in the matrix, he is shown the previous matrix versions by the architect? its that feeling, but in this case there is no version of reality where there is a win. The biggest problem I see even if this were to work, is that you don't really want non-developers using these tools. Who's to blame when the low/no code user makes a booboo ? These people typically don't want this burden, so I've always seen it pushed back to a developer...and the requests are usually beyond the scope of the low/no code tool such that it eventually always becomes a worse burden for devs than code
If you use this stuff right -- citizen-developers should be developing their own work.
Or at most, the work of their immediate group / team.
Who's to blame when the low/no code makes a booboo? The citizen-developer. And who fixes it? The citizen-developer. And who can fix it, because they already know how to do the work manually? The citizen-developer!
And, most critically, who is then incentivized to correct their own low/no code so it doesn't break again? The citizen developer.
The central organizational anti-pattern around this is "users build + IT maintains." Just... don't do that, or allow it. Make it clear when they get this capability, that they're responsible for fixing issues, and that IT will only advise.
And have that talk with their VP up front, so that when he or she tries to escalate because they have an "Oh @&$+" outage, you let them suffer long enough to hurt, before pitching in.
And then after the incident is over, you return with "So one way we prevent this on the other side of the house is {cvs/testing/environments/etc}..." And there's a chance they listen to you, because it's a solution to a problem they just had.
In my experience there is one situation where no code shines, namely, in enterprise support and deployment assisting software.
I've worked at a company that sold products to enterprise. There you have programmers writing complex features but you also have complex per-client requirements. Basically, software engineers maintained a nocode product that support / solution engineers use (not so much end users). So yes, there is a real programmer in the loop, but surprisingly, things also often get done without involving this programmer.
So many good points here, best summary of the problem of no code I've read yet. Whether you write lots of code or no code, all the principles you mentioned remain i.e. testing, deployment complexity, maintainability, rollback, release strategies etc. If you tried to do all that in a no code environment it would be horrendous. If you skip it, as a non engineer might, you're courting catastrophe.
No code will often make little sense for a lot of "proper" software if you want something maintainable, extensible, safe, performant (add other engineering principles here). It's probably very useful for non devs to build tools and cobble things together, in a similar fashion to how Excel can replace certain programming tasks. Just don't build your whole system from these things.
I think it's important that people respect the limits of these, no doubt useful, tools. We should also respect us software engineers and understand why we do things in the way we do. It might seem too complex but you might be suprised how complex, potentially unsafe and limiting the alternatives can be.
I think this argument against low-code is based on a misunderstanding of how most companies are staffed.
Truth: in normal companies, there are never enough software developers to build everything that needs building
Consequence: tons of processes and people get by as best they can, their never-prioritized project languishing in IT's backlog, often manually processing things that could be trivially automated
Consequently this isn't about a choice between (traditional software development with all the trimming) vs (low-code). It's a choice between (nothing/Excel) vs (low-code).
And given that reality, I'd argue that moving to a well-integrated, gutter-guards-in-place, documented low-code system is a HUGE win for the company as a whole.
And sure, you can say "It isn't this or that" (that should be there in well designed software). But it's also a helluva lot better than what they were running their part of the company on before.
Not really. I've granted that there is a middle ground, it's just that you have to draw the line at systems that actually need proper engineering eg where security or performance has serious real world consequences. It's a question of where you draw the line. Use this for appropriate use cases but beware of abusing this stuff.
Every system should have proper engineering. Most systems need proper engineering. Few systems actually have proper engineering.
I've seen stuff that has core-business, real world consequences, to the tune of affecting company's quarterly results, run off an Excel spreadsheet. And I don't think this is abnormal in large business land.
So the line shouldn't be drawn at "Is this system too important to trust to low-code?"
It should be drawn at "Is this system important to us?" + "If so, are we willing and able to assign development resources at it, to do it properly?" + "If not, what do we need from a low-code interim solution to keep it safe and maintainable?"
If we can't fix it properly, then it's counterproductive to enumerate the ways the fix we can apply is less than perfect.
You said it really, we're already drowning in dodgy systems code or no code. I'm just concerned to not make the problem worse with an even more powerful way to cause a disaster. Think the excel spreadsheet powering the quarterly results on steroids.
I don't deny there's a place for no code, I'm just sceptical about intended uses. Not least because a lot of what is written are puff pieces by someone with an agenda. This is big business.
It turns into a house of cards even when professionals use it.
Oracle Apex is a great tool for simple CRUD and reporting apps. But as systems grow big, you start to have complex flows, integrations with other tools (for file conversion, image manipulations, etc). and it becomes a big mess.
Yeah, the biggest flaw with the low/no code solutions is that end users want, and get, access to how the workflow works and/or it ends up this giant hero workflow handling every single possible scenario.
Best to keep the task simple, pick up the response, do some sort of identification, pass on it to where it should go. That's it. Let the next destination handle more stuff.
The challenge of programming is not really about writing in a programming language - it's about thinking, problem solving, and organization.
What low/no-code does is remove the setup and tooling barrier. I believe it's this barrier which scares most people away from programming. After all, even as an experienced software developer, I find some languages more intimidating because of the many tooling choices and setup options required before one can actually do something useful (front end development, anyone?).
Ruby on Rails did this for web development 20 years ago. It's way more complex now (partly because our expectations and desires are so much more complex), but when it was new it was essentially low-code compared to alternatives. And just with modern low-code systems, people who aren't good at thinking or structuring often create bad or unreliable things.
I'm sure more than a few of us have seen some of the monstrosities created by users with Excel. On the other hand, some non developers have created brilliant solutions in Excel. The same will be true of official no-code tools.
Where no-code can really benefit most, is by allowing some end users to attempt to solve their own problems. Chances are they won't end up with complete solutions, but they may end up with a clearer picture of what it is they want; and then they can go to professional developers and better communicate their needs. Maybe we'll end up throwing away less work as our solutions will better match the users' needs.
Exactly that. Also in my expereince as a Data Science consultant was that by far the best approach was to just rebuild what they attempted in excel in python. Also now that I think of it Excel is the original low code solution haha
I'm surprised how infrequently this comes up, given the massive usage of Excel in the business world; low-code/no-code is always discussed as if it's something new. Non-programmers in corporate America have been building excel applications for decades. You'd be surprised and a little scared by how many business critical processes depend on an excel workbook stored on a sharepoint somewhere.
Interestingly enough, Excel in many ways is also a sort of functional programming for the masses. Excel functions are (mostly) pure. Columns are sort of immutable, and you tend to build applications as collections of smaller functions composed together as you might in Lisp.
This came up in the thread on Bank Python (last week?). These systems have frameworks for implementing Directed Acyclic Graphs of functions in Python to simplify migrating Excel workflows into peer reviewed, version controlled code.
Let me tell you: no/low-code solutions can be just as hard as if not harder than actual code in some cases. One of the more difficult engineering solutions I have had to implement in my career was with a tool called Tasktop, which synchronizes different requirements analysis tools like Jira, Jama, GitHub Issues, etc. No actual code is involved (unless you need to add customization scripts), but you definitely want experienced engineers creating these integrations, as there are a great deal of software engineering concepts that need to be understood in order to understand and create successful integrations. So “democratization” of programming is misleading for low/no-code solutions, as non-programmers will quickly find themselves in trouble and eventually hand off the solution to a an actual software engineer.
Yeah, my face twitches whenever I see "no-code" solutions erect edifices of loops, conditionals, workflows, formulae, versioning and clever IDEs. I wonder if whoever POs this stuff is just oblivious to just how deep this rabbit hole of turing completeness goes.
It's bad enough when ansible does conditionals and loops with YAML. It's 10x worse when somebody thought they'd made the process easier because you have to drag and drop a box. There comes a point when most of these systems should just hand over control to a popular programming language with decent tooling OR a person and they almost always fly right past it.
It’s not that low code isn’t hard, it’s that it isn’t code. Which for the life of me I will never understand. But I’ve seen entire businesses run on linked spreadsheets with formulas that would melt your brain. All built by people terrified of “code”.
The problem with many low-code platforms is three fold:
- many over-promise and under deliver. Low code platforms are great for simple CRUD apps, defined automations, etc.
- some, like Bubble, are anti-code to their own detriment - code is good, your platform was created with code
- only a few, like Budibase [1], Tooljet [2], n8n [3] are open source. I cannot understand how users are willing to bet their data and processes on closed source tooling
Looks like you are associated with Budibase from your previous submissions & ideally you should have disclosed it to let others reading your comment understand your bias
They commented in another thread that they are the founder of Budibase. It doesn’t seem like they’re trying to hide their position. I’m not sure a disclaimer on every comment is warranted, nor desired.
By your logic, shouldn’t you also disclose that you are a marketer for a for-profit no-code app platform?
You can checkout Obsei as well: https://github.com/obsei/obsei. It is Apache 2.0 licensed.
It an open-source low-code cognitive automation tool. It observes unstructured text from various sources like app reviews, social accounts etc and then apply NLP tasks like sentiment analysis, classification and then inform/intimate user at given platform like slack, api etc. Currently support text based automation workflows but in future plan to include audio, video, and image as well.
All this posts miss the best low code environments of all time: Microsoft Access and FileMaker Pro. Unfortunately these two never made it to Internet era in big time and we have greatly come down from 90s RAD movement.
I got into real software development by writing a inventory management tool using MS Access back in the day.
It worked great! The application even looked almost like a normal Windows app. I wrote all of it by myself without knowing much coding (though I did write lots of VBA).
My first 'programming' job (around 1996-97) was doing Lotus Notes and Domino development. It's sad that Notes is mostly remembered as a really shitty email client[0] these days. The place I worked at had built it's entire workflow and document handling system in Notes/Domino, including an easy to use web client for the users using *nix workstations. It was in incredibly productive and easy to use environment that in many ways I've yet to see an equal to.
[0] ironically, the one thing we didn't use Notes for was email.
Are there any FMP like low code products that would also allow user sign up/sign in? I believe the problem with Access/FMP were that they were single user or trusted user setups.
FMP supports multi-user setups. You can even use external auth servers including Google login now.
I don't know if you can create a "new user" flow in your app, but you can add/register users and assign them to permissions groups from the FMP admin dialog.
What I'm generally amazed by is MatLab. They went from a general Math IDE to being an actual physics simulation environment...that now transpiles the symbolic flow based programming view to an external C-compatible library.
With this solution they are the only alternative, dominating whole industries with it. There are so many engineers with a no-coding background that literally build programs that end up as parts of firmwares on controllers...through MatLab.
Whether that's good or not (from the security point of view) is up for discussion. But I'm kind of amazed by the "compiler pipeline" that they achieved.
Imagine something like this combined with LLVM and an LSP based backend that also integrates a no-code way to implement fuzz and unit tests.
> Matlab isn’t umm... no code! It’s a programming language
All low-/no-code solutions are programming languages. Some of them are visual and lots of them have limited tooling support outside of a narrow solution stereotype, and they tend to defy superficial expectations about programming languages, but they all are programming in one form or another.
Am I the only one here who remembers MS Access? It was a great no-code/low code product that created silos of information in many organizations and it was a real PITA to transfer it to other technologies.
The advantage in MS Access was that it was part of the MS ecosystem and used VBA which is well documented. What will happen when you'll want to transfer something you've made in today no-code solutions to another platform?
I've seen this in different organisations: an accountant writes an MS Access app and when he cannot handle it anymore, he hands it over to IT (which is always so slow to provide solutions because they keep worrying about security, interoperability, consistency, and such).
One such app had in all its tables a column called "useless". It turns out it was the primary key. The author didn't know what it was for and didn't figure out from its name that it was important. There were also foreign keys referring to the description columns, not the primary key column (which was useless, after all).
In one instance, I saw an IT manager being asked for support for an app he had never heard of. It was another attack of the coding accountant! I call it code and run.
Newer solutions which use abstraction layers like postgREST will hopefully result in easier migration down the road - but I doubt most products/projects use such a thing.
What if i tell you, code is the "no code" tool itself.
Why ?
You of course could run any code with assembly or machine language, but now we have high level programming languages, it's because we want "low-code", or "low machine-code".
The point is we want to map business problems/solutions into machine, code is just a "no code" tool which allows u to do that.
Yep. The problem is not that that programming languages are create an undemocratic force field around programming, it's that only very few people can efficiently translate any sort of requirements into any sort of machine-comprehensible instructions, doesn't matter if it's code, excel formulas, multitude of ERP checkboxes or something else.
The high demand and pay of the last few decades brought a lot of people into trying to be those few but it looks like the percentage of the "worthy" people remains as low as it was decades ago and move from Fortran to lowcode did nothing.
The issue is how the education system and teachers don't know the principles behind programming. They teach Algebra but they can't apply that knowledge to programming.
The thing I'm finding hard to get my head around is people who are arguing that various languages such as COBOL or Python are, or might be considered low code or no code.
To anyone who needs to hear this: if it's code based programming then it's not no-code or low-code - it's code.
Well, the goal of COBOL was to make something that everyone could use, so that professional programmers would be obsolete. It didn't succeed, and it doesn't look like "no code" to us today, but the goal was the same.
But it's never really "no code". There's always "code", because you always have to tell the system what you want the program to do. However you tell it that, that description becomes the code.
COBOL and 'modern' Fortran (aka FORTRAN 66) where very much designed with the goal of making programming something that 'everybody' could do without having to learning about actual programming and computers and all that 'boring' stuff.
Each one involves telling your computer some logic, but on the left you have to be much more detailed and the computer makes fewer assumptions than on the right. Is Hasura Code or No Code™? I write some SQL or a GraphQL query, but I also click around and set permissions and relationships in a GUI.
For me, the low code perspective is a little different.
I think that no/low code is the secret end goal for any B2B line of business product. You eventually want to be able to have sales engineers directly setting up your products for customers, with developers standing by to support or enhance the shared code pile. You never want to be in a situation where you need 1 developer and code pile per customer when you are trying to capture an entire market segment with hundreds or thousands of businesses.
Once you figure out all the likely paths through the jungle, you can expose configuration and scripting at the various decision points.
Our specific flavor of "low" code leverages SQL and projections of business state to allow for very precise tuning of certain logic. Being able to employ SQL to solve problems implies a very intimate understanding of the problem domain. You have to do battle with the business and iterate the model until you know 99% of it will never have to change. Anything less than this is walking across quicksand, as changes to schemas per already-configured customers quickly turns into a nightmare factory of regressions and otherworldly suffering.
There aren't enough people who go into coding because most people simply dislike coding. I've seen it many times and don't blame them. I love coding, but dislike chemistry and statistical analysis. It's just not my thing
Since this is likely not going to change, these no-code tools expand the number of workers who can do stuff. But it clearly isn't as good as coding and never will be
> In the past decade, the growth in low-code and no-code solutions...
The articles then shows that it is far from a "past decade" thing.
Low-code, no-code, RAD, or whatever you want to call it has always been a thing. Code is an obscure thing to the uninitiated, and it costs a lot of money to hire the initiated. So of course people want to make it more accessible. Today is nothing new, if anything, it tends to go the other way: people are getting more comfortable with code.
And the article explains it very well, in fact, it is one of the best overview I've seen. It takes about Excel, the most successful "low-code" platform, UML, which is mostly a failure, and modern takes like Copilot which offer guidance but do not try to hide the code.
The conclusion however seems to be "I don't know", told in a particularly convoluted way in entire chapters. I think the article would have been better if it didn't try to predict the future.
The contributions of communities in the growth of programming languages is huge. If no-code/low-code is looking at a similar trajectory, open-source frameworks might prove to be the best options.
> Extending fundamental software development practices like version control, automated testing, and continuous deployment to other low-code and no-code tools sounds like a job for programmers, and one that’s still on the to-do list.
This, so much this!
The amount of wilfull low-code ignorance of standard, 20-year+ old best practices for producing reliable software is mind-boggling.
Integrate with standard version control. Have a textual representation of your source. Integrate with standard CI/CD.
No, you are not a special snowflake. And no, no one wants to have to use your cloud SaaS build tools vs something they can own, integrate, and run themselves.
Like isn't a turing complete language proven to be the highest level one can go to be able to do anything required with code?
Everything past that reduces the amount of code but also reduces the number of things the code can do and at some point in the code reduction, it's just a declarative language?
Its all shades of gray between imperative/functionsl and declarative.
Democratization of code will be the same as the democratization of medicine: anyone can go to a pharmacy and buy aspirin, ibuprofen, vitamins, etc. That doesn't mean physicians are jobless. Also if you have some serious problem or disease you shouldn't self medicate, but get professional treatment.
The one thing I worry about is security. How do you make low code tools flexible enough to be powerful while retaining security? On the other hand, maybe for the use cases that are well supported, these tools could provide security by default instead of relying on individual engineers to get it right.
A lot of it will be pushed down the stack into infrastructure. Infrastructure typically tails software, so over the next decade I would expect to see shifts in the infrastructure to accommodate this.
For example, I think we'll start to see more fine-grained ACLs in databases combined with passthrough authentication from the webapp. So the nocode app is basically just a layout engine that passes a query and your Okta token (or whatever) to the database, which runs the query and filters out results you personally can't access, and then nocode app formats it (basically, in a naive implementation).
IT gets to maintain control of the ACLs, and permissions become seamlessly uniform across applications. Marketing doesn't have to talk to IT get to credentials for the database and talk about security, they just set up a new app and the database makes sure that users are allowed to access that data.
That will also cause a cottage industry of tools for managing those permissions to spring up.
I would keep a serious eye on Microsoft in this space. Active Directory + SQL Server gives them serious inroads into major companies for something like this. Sharepoint is also already in the same vein. If they bought out a nocode platform, replaced Sharepoint with it and integrated the ACLs for AD and SQL Server, they could have a really compelling product in this space. It would be a perfect add-on product for Office 365, and the billing is already set up for a lot of companies.
I'd say Microsoft already has this with Dataverse/Power platform? It runs on Azure SQL Server but it is not exposed directly nor uses SQL server's ACL. Instead, the available access points -- mainly its web API -- honor the permission system configured on the platform, whether it's coming from apps themselves, custom JS code or reporting tools like PowerBI. Users are of course AD users.
Model-driven apps on Dataverse are exactly how you'd imagine MS Access if rebuilt as a SaaS product, and they integrate with Office in various ways. One Azure tenant gets one Dataverse database-- it's certainly intended to host multiple apps sharing the database.
Main problem is that building meaningful LOB applications on this type of low code platform is difficult. Works well for a toy project, or ends up being engineered solutions maintained by IT -- neither hitting the sweet spot mark. I guess general purpose low code is hard.
> For example, I think we'll start to see more fine-grained ACLs in databases combined with passthrough authentication from the webapp. So the nocode app is basically just a layout engine that passes a query and your Okta token
I think you can set that up with Postgres using row-level security and a generic "REST to SQL" frontend whose name escapes me. Harder business logic can go in stored procedures, which Postgres allows you to in a range of languages AFAIK. It seems like a great architecture to me, and it should also be some kind of simple to wrap a generator around it with a nice UI.
One of the important issues that the no-code world hasn't really come to grips with is security. Generally speaking, you have similar security issues (not exactly the same as there are no buffer overflows or js-eval/java-object injection attacks) but the code is being written by non-experts. That means all the subtle problems of faulty business logic in which end users or third parties are given too much control is going to bite you bigly.
Moreover, it's a myth that "no-code" code is easier to read or less buggy than traditional code. Moreover the lack of propery IDE support, often improper version control, and difficulty of extracting the no-code from the platform for proper analysis makes it very hard to audit in a systematic way. And the existing security tooling can't understand it. We are going to end up with piles of this stuff, often highly privileged code, written by non-experts, running on important high value systems.
Programming is inherently hierarchical profession, because it's one of the few that progresses by automating itself. Therefore it will never be "democratized" (by this the author means equality). At the bottom of the pyramid sit the Excel-handlers and people who "program" a few lines of pre-made templates. At this level programming is similar to a GUI, a language that appeals to intuitions of everyday life so that it can be approachable to everyone. But as you go up the hierarchy of building things-that-build-things, the wealth is increasingly concentrated. At the top sit the 1% Gurus whose job cannot be automated away, and who can command the whole economy with their choices. You can't fight this hierarchy with "nocode" toys, it takes work
There's a disturbingly large number of people who look at computer programming, say "this is too complex - programmers must be artificially making it complex to keep me out".
I think "low code" and "no code" just like making module. It simplifies the unlimited possibilities from code to a pre-compose and limited modules.
As you entering a restaurant, and you see the menu all the material is available to customize but having 1000 options. And you find there are a few default combos beside that. I don't think most of people will choose "customize" after they fully understand all the options.
I guess 80% people only need a basic functions. To engineer, that's a simple work. But to people who cannot code, that's extremely hard.
There is a space for low code solutions but you have to know the tradeoffs. I think low code belongs to initial MVPs you know you will have to re-build. Low code wont scale. Low code at some point will be an absolute pain to iterate on. Low code is super hard to collaborate on. But initially none of that matters. I think the biggest problem in software engineering is not scaling or nice code structure or design or collaboration or whatever but to build something people want to use. This goes for startups as much as for Enterprise apps.
Also I think if low code and no code industry are more steady. It'll more like the traditional operations.
There're upstream, midstream and downstream. (Low/No code probably will be upstream or midstream) They need to take care about the QA & QC instead of normal software development flow. Because one mistake will affect all the downstream used.
A bad low-code experience is being forced to manipulate endless drop-down menus and checkboxes when it’d be 10x faster to just write a SQL query. For example, Salesforce. Ideally you should be able to drop down a level in any such tool (e.g., Excel to VBA, Python to C).
My experience has been the complexity is still there somewhere. Just not in the form of what we normally refer code. Often pushed down to the database in the form of bloated procedures and views. If it is not in the application layer it is "low-code".
From my seat on business side it's becoming increasingly harder to source engineering talent as quickly as we could before so I expect this will drive further proliferation of nocode solutions to business asks.
> Another way of looking at low-code is to take an even bigger step back, and look at the history of programming from the start. Python is low-code relative to C++; C and FORTRAN are low-code relative to assembler; assembler is low-code relative to machine language and toggling switches to insert binary instructions directly into the computer’s memory.
That is the most stupid thing I've read in a while.
> That is the most stupid thing I've read in a while.
Arrogance.
It takes 10 lines of Python to compute a multiplicative inverse mod p, using arbitrary precision integers. [1] Try doing the same thing with nothing but x86 assembly and Volume 2 of Knuth's AOCP.
arguably, higher level language use higher level general code features, where-as no/lo-code solutions are using specialised/domain features.
This would make them similar to a framework like chef/ansible/puppet that requires a large library of "knowledge" on how to do various things (all written in traditional low/high-level general code).
First, it's not "low-code" or "no-code", it's high-level code vs. low-level code vs. non-traditional non-text-based code like labview. But it's still code, there's always the code.
Second, learning "code" or "coding" isn't the problem in democratizing "programming" in the first place. Code is the easy part. Software engineering, architecture, debugging & troubleshooting, logic, math, configuration management, project management - that stuff is the hard part. It's of absolutely no help to have a bunch of smart domain-experts happily "no-coding" away in matlab or labview or excel or ms. access and then stumbling right into the same bad engineering practices that you might find in struggling projects using traditional tools.
That's because we don't need "coders" or "programmers" at all. We need people to be engineers. And part of good engineering is picking the right tool and system to use, not jumping on the next over-hyped fad.
Proponents often cite how much quicker they can ship things and how it lets users define and automate their own workflows without waiting for engineers. The reality is that these time savings come by cutting corners from the development cycle. Because you're not doing "code", the code review step gets skipped. The authoring of automated test suites get skipped. The authoring of performance regression testing gets skipped. There's no waiting for things to bake in non-prod environments because people are changing settings directly on prod. No ones doing phased deployments with automated rollbacks here in these low code and no code environments. No design reviews mean you get solutions that are the absolute worst hacks.. Why go through the work of making "priority" a first class property on your ticket type when you can just string scan for "high" | "medium" | "low" on case titles when doing assignments?
Engineering teams could also move fast if they just threw maintainability to the wind. There's a reason they don't. If you do things the right way in these low/no code environments, the complexity is even worse, because the features are so half-baked that you can't setup proper safeguards without doing crazy amounts of escape-hatches.