I've seen "low code" and "no code" solutions running at huge enterprises and it always inevitably ends up resembling a house of cards.<p>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?<p>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.
The challenge of programming is not really about writing in a programming language - it's about thinking, problem solving, and organization.<p>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?).<p>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.<p>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.<p>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.
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.
The problem with many low-code platforms is three fold:<p>- many over-promise and under deliver. Low code platforms are great for simple CRUD apps, defined automations, etc.<p>- some, like Bubble, are anti-code to their own detriment - code is good, your platform was created with code<p>- 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<p>[1] <a href="https://github.com/Budibase/budibase" rel="nofollow">https://github.com/Budibase/budibase</a><p>[2] <a href="https://github.com/ToolJet/ToolJet" rel="nofollow">https://github.com/ToolJet/ToolJet</a><p>[3] <a href="https://github.com/n8n-io/n8n" rel="nofollow">https://github.com/n8n-io/n8n</a>
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.
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.<p>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.<p>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.<p>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.
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?
What if i tell you, code is the "no code" tool itself.<p>Why ?<p>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".<p>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.
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.<p>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.<p>Put more simply:<p>code != no-code
For me, the low code perspective is a little different.<p>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 <i>per</i> customer when you are trying to capture an entire market segment with hundreds or thousands of businesses.<p>Once you figure out all the likely paths through the jungle, you can expose configuration and scripting at the various decision points.<p>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<p>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...<p>The articles then shows that it is far from a "past decade" thing.<p>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.<p>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.<p>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.<p>Examples:
ToolJet: <a href="https://github.com/ToolJet/ToolJet" rel="nofollow">https://github.com/ToolJet/ToolJet</a>
Obsei: <a href="https://github.com/obsei/obsei" rel="nofollow">https://github.com/obsei/obsei</a>
n8n: <a href="https://github.com/n8n-io/n8n" rel="nofollow">https://github.com/n8n-io/n8n</a>
> <i>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.</i><p>This, so much this!<p>The amount of wilfull low-code ignorance of standard, 20-year+ old best practices for producing reliable software is mind-boggling.<p>Integrate with standard version control. Have a textual representation of your source. Integrate with standard CI/CD.<p>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.
So, regarding Excel, those bean counter guys from accounting in Sumer were onto something timeless?<p><a href="https://www.christies.com/lot/lot-a-sumerian-clay-cuneiform-tablet-third-dynasty-5903826/" rel="nofollow">https://www.christies.com/lot/lot-a-sumerian-clay-cuneiform-...</a>?<p>By the way,do you think anybody will pay that much for an 4000 year old Excel Sheet about let's say pork belly futures in that 4000 years?
Isn't regular code, low code?<p>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?<p>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?<p>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.
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
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.<p>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.<p>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.<p>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".
I think Low-Code is the way to solve repetitive tasks and be more productive.<p>Current favorite low-code tool: <a href="https://github.com/ToolJet/ToolJet/" rel="nofollow">https://github.com/ToolJet/ToolJet/</a>
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.<p>That is the most stupid thing I've read in a while.