IMO the problem with low code is, that the hard part about solving most problems isn't usually the way you write or execute it.
The hard part is avoding weird edge case logic errors, race conditions, all these things good programmers will avoid by having an intuition of complex systems with state spread around. This is what you pay software people for, and not for the ability to crank out text in languages that look cryptic to commoners.
Now I do think that such low code environments can provide benefits in specific situations (e.g. when you use it as a highly flexible "config file" within the framework of another system that catches all those forbidden states).
The other problem with low code is that the visual abstraction can often make it harder to grok. I've had the unfortunate experience of spending hours trying to click through different nodes of a moderately complex Salesforce flow to piece together WTH it's doing.
It's also impossible to diff two across revisions.
If the same solution were written in code using high level libraries it would be a few hundred lines.
I wish these low code solutions would build on top a traditional text based language and allow you to flip back and forth.
> Low-code enables domain experts to become citizen developers.
I have yet to see a single "citizen developer" successfully building stuff using low-code/no-code solutions.*
> At the same time, low-code platforms should also strive to make pro-developers (professionals with an education or career in software development) more productive.
This is mostly what I see.
Occasionally, I see real developers sticking with the low-code/no-code solutions far beyond what it should ever be used for, to the detriment of the product.
What I do see a lot of is people with a long history in the business aspect being brought in as program managers, QA testers, UI designers, etc. They are generally very successful in those areas.
*VB6 and Visual FoxPro I have seen business people building production apps with. You may not consider those to be "real" low-code/no-code solutions, but... I've seen business people teaching themselves those to build their own stuff.
> I have yet to see a single "citizen developer" successfully building stuff using low-code/no-code solutions.*
I've seen plenty, in billing reconciliation, marketing, fraud detection, etc. in major telcos. I've also trained non-programmers to do this, with success (even adding enough Python to create custom nodes for scenarios where no prebuilt block is suitable).
Also, plenty (millions?) of citizen developers have built complex "applications" in Excel.
Not sure if this counts, but many successful games have been made with Game-maker-style tools, which I think would be classified as "low-code". E.g. Undertale
Excel sheets and now Airtable bases are another way to build apps I see pretty often. The problem is when these things outgrow their original platforms there's a huge step in effort up from "simplify the formula/query" to "ingest all the data into a database then write a view on top". My own wish for low-code tools is to cross this chasm.
Just looking at code that QA or Ops people write makes me unbearably nervous. Look at all of these load bearing posters everywhere.
And those people have been thinking about software their entire career. Domain experts being embedded in Agile teams is not so they can keep an eye on us, it’s so we can keep an eye on each other.
I've long been interested in low-code, because it's one of those things where the benefits seem obvious, but become less obvious the more you think about it.
In some cases the benefits are plain to see. For instance, if you needed to represent a squiggly line in SVG, the natural movement of a user's hand guiding a digital pencil is going to be far superior than writing out each x/y position in a vector path.
But other use cases aren't so clear, and in fact, many tasks could be made far more efficient with a textual interface.
I think the reason people assume that code is time-consuming or complex, is because historically it's been used to solve complex problems that non-technical users don't understand. So in other words, they don't understand the problem domain. My theory is that if they understood the problem domain, then they could understand any formal syntax dedicated to the domain.
As an example, the following pseudo-code:
begin dishwashing:
gather(plates)
sink.load(plates)
each plate(rinse)
each plate(dishwasher.load)
dishwasher.on()
end dishwashing
Everyone understands the problem domain (how to wash dishes), so even though someone may be unfamiliar with historical programming conventions and syntax, they should be able to grasp what the code does.
It's something I'm exploring with this language I've been building called Matry: https://matry.design.
The key problem that creates "low" or "no" code products is a pattern that shows up in a lot of technical fields: non-technical people run into the first hurdle, and assume it represents the majority of the difficulty. In software, this is sourcecode syntax. Somebody who's never written a line of code in their life sees source code, can't read it straight away, and assumes "We pay the software developers lots of money because they can read the cryptic runes" and goes on to pitch some "revolutionary solution" that eliminates this very minor hurdle, assuming that it will make the whole thing easy.
You see the same thing in discourse about science and math: "If we could just eliminate all the jargon and syntax, anybody could understand a scientific paper". In all cases, they're wrong, of course, since the syntax and jargon are such negligible hurdles that by the time someone is technically capable enough at the actual problem they'll come as second nature, but the non-technical folk don't ever reach that level of understanding.
Then this solution gets sold to other non-technical people, who, falling into the same trap, integrate it into their workflows.
Tangentially I want to mention that rinsing dishes before running the dishwasher is a known anti-pattern. The first washing cycle is exactly that - a rinsing cycle. I know this is off-topic but saving water is always a good idea.
In my experience visual tools like RoseRT can quickly turn into an obstacle. I think it's super important to not only know what the non-code solutions may be good at but also keep the solution limited or at least be prepared to go back to code if the problem domain is complex enough.
begin dishwashing:
gather(plates)
sink.load(plates)
each plate(rinse)
each plate(dishwasher.load)
dishwasher.on()
end dishwashing
I guess this is the problem with "low code". An actual dishwasher program would maybe look something like:
/* Setup some arcane registers and timers */
...
init_program (&setup); while (state == WASHING);
// enable_pump (78); while (state == PUMPING); // 62 too fast - Fred 2007
// enable_pump (81); while (state == PUMPING); // For Peru market - Kim 2011
enable_pump (1); enable_pump (1); enable_pump (1); // Relay maybe stuck tickle it
enable_pump (11); while (state == PUMPING); // ???
enable_pump (99); while (state == PUMPING);
...
But obviously without the comments. Sooner or later many programs need complex state machines and some order at the language level the keep our sanity.
Low or nocode is imho not the holy grail for solving business IT problems. Low code or mda like tools have since 1980 be promoted using several names. have, e.g.:
Low code tooling
No code tooling
Model Driven Engineering (MDE)
Model Driven Design (MDD)
4GL tools
Low code tools are not strong on versioning and dealing with multiple parallel development tracks and teams simultaneously. Most tools are in fact based on a big design upfront paradigm, like an overall data model. Versioning on models, meta data and data of all created and generated software assets is poorly supported, if supported at all. Common practices seen in mature agile software development tools using micro services paradigms and advanced distributed version control systems are often lacking in the new low-code MDA family of tools. In large companies it is not uncommon to encounter models with hundreds (or even thousands) of entities / classes. That kind of models not only doesn’t help with developing software faster and more cost-efficiently but even has an adverse effect.
Low code tools have a strong focus on initial productivity gain. But a continuous fast changing business context with changing requirements requires an approach and toolset that is suited for giving long term productivity benefits.
> Low code tools have a strong focus on initial productivity gain. But a continuous fast changing business context with changing requirements requires an approach and toolset that is suited for giving long term productivity benefits.
The best "low code" tools absolutely meet this requirement and best of all, don't _feel_ like programming to the users. Spreadsheets are the most obvious example.
I have been doing a lot of work with AWS StepFunctions lately, everything from replacing cron jobs to implementing HTMX backends. I think StepFunctions is an interesting case study (I'm not really familiar with other offerings, other than spending some time with the block-based programming like Scratch and MakeCode).
To build solutions I have to use the Amazon States Language, which is a learning curve and being as charitable as I can a royal pain in the ass. Ultimately I end up with a JSON file that is a "giant, flexible config file" for their runtime.
On the plus side, solutions using it are very nearly zero maintenance. No runtime updates, no package updates, no manual scaling, etc.
Another plus, it's zero cost when not in use. No VMs I have to pay for hourly or monthly.
The downsides (for me) are obvious: It's difficult to learn; It's very restrictive, and solutions often end-up needing some aspect of more flexible services like Lambda or Fargate (containers) when end-up adding cost and maintenance; It's proprietary and there is nothing I can use elsewhere (no other company support ASL as far as I know).
Overall, though, I love it. Why? I despise having to choose between unpatched systems and the drudgery of constant patching. With StepFuctions I don't have to choose.
I was so stoked to build stuff this way; I had the same sentiments about the learning curve, but overall it seemed like an amazing tool and pretty fun.
The problem is the people around me thought it was too difficult, and couldn't see long term. So we implemented a low code solution and now everything is in there and it's a mess/nightmare. I hate my work now, and everything we build is tightly coupled to this spaghetti platform that will inevitably decide to raise it's prices on us and we will have no recourse.
Job hunting has been tough too, because very few places have done this, so they ask "what have you been working on?" and I'm basically setting record times for ending interviews if I tell the truth.
I'm currently using a low-code tool for prototyping an app [1] together with a team that has no professional software engineers (although there are researchers capable of programming in Python/R).
I found the tool super easy to use and we managed to have a functional app in one afternoon, but when they tried to use it themselves it wasn't as intuitive – the tool works best if you already posses some intuition of relational model, CRUD patterns, etc. Without this intuition the other members were having a hard time understanding how to better structure the data for the app, and started trying to "hack" it to make the app work the way they expected instead of working with the abstractions available.
Is there an open source Low-Code system that works?
Where I work we currently have 2 low code tools for automating internal business processes.
Now a new executive has appeared and his answer to two of these systems is to get a third. This time it will be MS PowerApps.
It seems that Low-Code is all high cost. The costs for licencing these platforms is 1-2 developers per year for our organisation of roughly 800 people.
No doubt making applications on the web that work with SAML integration is harder than it could be, but the low-code tools lack of versioning and the ability to do automated testing is poor. Especially given the licencing costs.
Even a good web based GUI for drawing UI's would be useful. But cost really is a factor.
Visual Basic was a low code tool that did enable non-coders to create applications that were useful. It appears that the current crop of low-code tools are not near VB's ease of use or utility.
you should try windmill.dev, semi-technical folks can use the webeditor and the built-in versioning while more senior folks can keep their IDE and version directly from github/gitlab.
Budibase is pretty good and helps you build simple web based solutions that can integrate with a wide range of data sources. Definitely worth checking out.
I remember after coding in C++ for 5 years and then doing Java and thinking it was like low code as java was so easy because of the memory management and gc
I am considering/designing/PoCing implementing a low-code (visual programming like Unreal) system for a specialized ETL (algorithmic) system. Both E and L would be nodes and the target audience mostly uses math in the T.
Great advantage seems to be an ability to schedule jobs based on algorithm needs, as everything is known in the graph. I also think we can give some guarantees like infinite loop prevention by analysing the graph.
An alternative I see is a textual DSL which may be even more work to implement and user discovery becomes harder.
I’d love to talk and discuss about this with others; it is hard for me to determine whether this is the way to go with so many opinions in either camp.
ETL is one of the places that NoCode LowCode solutions and Visual Programming systems have been successful despite the amount of negative information out there. They’re a sort of silent success story in the ETL works since 1: it’s not glamorous work so there’s not a lot to brag about 2: it’s often solved by just paying for some proprietary vendor solution since they will have already done the hard work getting the E and L parts done and plenty of companies have built compelling sales pitches about how simple the T will be with their drag and drop design tools and 3: once the ETL pipeline is done, a few revisions is usually all they get in most workplaces, and then it will run in the background silently until someone questions the cost of running it or asks where the data in some system is coming from or why they get some emailed reports.
The ETL niche is a good fit for the kind of approach you’re describing, so I don’t see any reason not to build at least a prototype to see how the end users like the design … beyond the obvious complexity of getting a visual node based editor and data format up and going (and there’s some open source out there that makes that part not as much work as it would have been 5-10 years ago)
"Low-code is about creating instructions for a computer to execute or interpret. These instructions form a computer program, typically in a domain-specific language (DSL). For instance, low-code is often based on search-based program synthesis, and synthesis usually targets a DSL carefully crafted for the purpose."
If that's the definition (and I agree that it is) then 90% of my code is low code, as that's how much is XML, XSLT, and SQL. In C# .NET 8, another 5% is Linq which is a DSL that I consider low-code.
I have friends who work for a company that sells a million dollar low-code data platform. Business is good.
The problem with low-code is the same as with outsourcing code on UpWork:
Security
You get something that works. But how do you know there is no way to:
1: Alter the code from the outside
2: Access parts of the DB one is not supposed to access
Those can only be avoided by a programmer who knows about all the weird edge cases that might lead to 1 or 2 and how to write a complex system in a way that is structured to make bugs unlikely.
(2) is not a particular issue with low-code, it's just a problem for everyone. I'm in a "high-code" environment and they still managed to fuck up data access controls. You have to bring on people (or give them authority) who understand how to secure your data. Afterwards, high-code or low-code you're going to be ok (maybe not great, but ok).
I wonder if there is potential to combine generative AI with low code approaches, where the non-coder would work with the AI on a higher order description of the problem (data, states, events) and the AI could generate the MVP code. It kind of seems that is the relationship we human coders have at the moment with non-coders. Maybe all those UML diagrams can finally be used as inputs.
Low code has been a thing in ETL data integration space for a long time. Anecdotally the most consternation I have experienced lately has been supporting buggy low code implementations which seem to becoming worse and not better over the last 20 years or so.
[+] [-] atoav|2 years ago|reply
The hard part is avoding weird edge case logic errors, race conditions, all these things good programmers will avoid by having an intuition of complex systems with state spread around. This is what you pay software people for, and not for the ability to crank out text in languages that look cryptic to commoners.
Now I do think that such low code environments can provide benefits in specific situations (e.g. when you use it as a highly flexible "config file" within the framework of another system that catches all those forbidden states).
[+] [-] ethbr1|2 years ago|reply
As soon as you drop into customized complexity, you should be building new low-code components with actual code.
Which I think is the main reason low-code is popular in the API-to-API SaaS space: actions are limited and well-defined.
[+] [-] cjonas|2 years ago|reply
It's also impossible to diff two across revisions.
If the same solution were written in code using high level libraries it would be a few hundred lines.
I wish these low code solutions would build on top a traditional text based language and allow you to flip back and forth.
[+] [-] hyperthesis|2 years ago|reply
I'm surprised TFA implies spreadsheets aren't still dominant.
[+] [-] anonzzzies|2 years ago|reply
... which will almost always trigger Greenspun's tenth rule
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] RajT88|2 years ago|reply
I have yet to see a single "citizen developer" successfully building stuff using low-code/no-code solutions.*
> At the same time, low-code platforms should also strive to make pro-developers (professionals with an education or career in software development) more productive.
This is mostly what I see.
Occasionally, I see real developers sticking with the low-code/no-code solutions far beyond what it should ever be used for, to the detriment of the product.
What I do see a lot of is people with a long history in the business aspect being brought in as program managers, QA testers, UI designers, etc. They are generally very successful in those areas.
*VB6 and Visual FoxPro I have seen business people building production apps with. You may not consider those to be "real" low-code/no-code solutions, but... I've seen business people teaching themselves those to build their own stuff.
[+] [-] michaelteter|2 years ago|reply
I've seen plenty, in billing reconciliation, marketing, fraud detection, etc. in major telcos. I've also trained non-programmers to do this, with success (even adding enough Python to create custom nodes for scenarios where no prebuilt block is suitable).
Also, plenty (millions?) of citizen developers have built complex "applications" in Excel.
[+] [-] amilios|2 years ago|reply
[+] [-] Karrot_Kream|2 years ago|reply
[+] [-] threatofrain|2 years ago|reply
[+] [-] hinkley|2 years ago|reply
And those people have been thinking about software their entire career. Domain experts being embedded in Agile teams is not so they can keep an eye on us, it’s so we can keep an eye on each other.
[+] [-] dang|2 years ago|reply
Tell HN: Enterprises spend 10 more to build no-code solutions than coded ones - https://news.ycombinator.com/item?id=37689282 - Sept 2023 (178 comments)
But the current article is quite substantive so we won't treat it as a follow-up the way we normally probably would (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...).
[+] [-] danielvaughn|2 years ago|reply
In some cases the benefits are plain to see. For instance, if you needed to represent a squiggly line in SVG, the natural movement of a user's hand guiding a digital pencil is going to be far superior than writing out each x/y position in a vector path.
But other use cases aren't so clear, and in fact, many tasks could be made far more efficient with a textual interface.
I think the reason people assume that code is time-consuming or complex, is because historically it's been used to solve complex problems that non-technical users don't understand. So in other words, they don't understand the problem domain. My theory is that if they understood the problem domain, then they could understand any formal syntax dedicated to the domain.
As an example, the following pseudo-code:
Everyone understands the problem domain (how to wash dishes), so even though someone may be unfamiliar with historical programming conventions and syntax, they should be able to grasp what the code does.It's something I'm exploring with this language I've been building called Matry: https://matry.design.
[+] [-] OkayPhysicist|2 years ago|reply
You see the same thing in discourse about science and math: "If we could just eliminate all the jargon and syntax, anybody could understand a scientific paper". In all cases, they're wrong, of course, since the syntax and jargon are such negligible hurdles that by the time someone is technically capable enough at the actual problem they'll come as second nature, but the non-technical folk don't ever reach that level of understanding.
Then this solution gets sold to other non-technical people, who, falling into the same trap, integrate it into their workflows.
[+] [-] badtension|2 years ago|reply
In my experience visual tools like RoseRT can quickly turn into an obstacle. I think it's super important to not only know what the non-code solutions may be good at but also keep the solution limited or at least be prepared to go back to code if the problem domain is complex enough.
[+] [-] rightbyte|2 years ago|reply
[+] [-] WalterBright|2 years ago|reply
[+] [-] runningmike|2 years ago|reply
Low code tooling No code tooling Model Driven Engineering (MDE) Model Driven Design (MDD) 4GL tools
Low code tools are not strong on versioning and dealing with multiple parallel development tracks and teams simultaneously. Most tools are in fact based on a big design upfront paradigm, like an overall data model. Versioning on models, meta data and data of all created and generated software assets is poorly supported, if supported at all. Common practices seen in mature agile software development tools using micro services paradigms and advanced distributed version control systems are often lacking in the new low-code MDA family of tools. In large companies it is not uncommon to encounter models with hundreds (or even thousands) of entities / classes. That kind of models not only doesn’t help with developing software faster and more cost-efficiently but even has an adverse effect.
Low code tools have a strong focus on initial productivity gain. But a continuous fast changing business context with changing requirements requires an approach and toolset that is suited for giving long term productivity benefits.
[+] [-] eschneider|2 years ago|reply
The best "low code" tools absolutely meet this requirement and best of all, don't _feel_ like programming to the users. Spreadsheets are the most obvious example.
[+] [-] mlhpdx|2 years ago|reply
To build solutions I have to use the Amazon States Language, which is a learning curve and being as charitable as I can a royal pain in the ass. Ultimately I end up with a JSON file that is a "giant, flexible config file" for their runtime.
On the plus side, solutions using it are very nearly zero maintenance. No runtime updates, no package updates, no manual scaling, etc.
Another plus, it's zero cost when not in use. No VMs I have to pay for hourly or monthly.
The downsides (for me) are obvious: It's difficult to learn; It's very restrictive, and solutions often end-up needing some aspect of more flexible services like Lambda or Fargate (containers) when end-up adding cost and maintenance; It's proprietary and there is nothing I can use elsewhere (no other company support ASL as far as I know).
Overall, though, I love it. Why? I despise having to choose between unpatched systems and the drudgery of constant patching. With StepFuctions I don't have to choose.
[+] [-] rangledangle|2 years ago|reply
The problem is the people around me thought it was too difficult, and couldn't see long term. So we implemented a low code solution and now everything is in there and it's a mess/nightmare. I hate my work now, and everything we build is tightly coupled to this spaghetti platform that will inevitably decide to raise it's prices on us and we will have no recourse.
Job hunting has been tough too, because very few places have done this, so they ask "what have you been working on?" and I'm basically setting record times for ending interviews if I tell the truth.
[+] [-] hcarvalhoalves|2 years ago|reply
I found the tool super easy to use and we managed to have a functional app in one afternoon, but when they tried to use it themselves it wasn't as intuitive – the tool works best if you already posses some intuition of relational model, CRUD patterns, etc. Without this intuition the other members were having a hard time understanding how to better structure the data for the app, and started trying to "hack" it to make the app work the way they expected instead of working with the abstractions available.
[1] http://appsheet.com
[+] [-] sitkack|2 years ago|reply
[+] [-] totetsu|2 years ago|reply
[+] [-] sien|2 years ago|reply
Where I work we currently have 2 low code tools for automating internal business processes.
Now a new executive has appeared and his answer to two of these systems is to get a third. This time it will be MS PowerApps.
It seems that Low-Code is all high cost. The costs for licencing these platforms is 1-2 developers per year for our organisation of roughly 800 people.
No doubt making applications on the web that work with SAML integration is harder than it could be, but the low-code tools lack of versioning and the ability to do automated testing is poor. Especially given the licencing costs.
Even a good web based GUI for drawing UI's would be useful. But cost really is a factor.
Visual Basic was a low code tool that did enable non-coders to create applications that were useful. It appears that the current crop of low-code tools are not near VB's ease of use or utility.
[+] [-] rubenfiszel|2 years ago|reply
The UI part is drag-n-drop;
[+] [-] wanderingmind|2 years ago|reply
[+] [-] zubairq|2 years ago|reply
[+] [-] rahkiin|2 years ago|reply
Great advantage seems to be an ability to schedule jobs based on algorithm needs, as everything is known in the graph. I also think we can give some guarantees like infinite loop prevention by analysing the graph. An alternative I see is a textual DSL which may be even more work to implement and user discovery becomes harder.
I’d love to talk and discuss about this with others; it is hard for me to determine whether this is the way to go with so many opinions in either camp.
[+] [-] techdragon|2 years ago|reply
The ETL niche is a good fit for the kind of approach you’re describing, so I don’t see any reason not to build at least a prototype to see how the end users like the design … beyond the obvious complexity of getting a visual node based editor and data format up and going (and there’s some open source out there that makes that part not as much work as it would have been 5-10 years ago)
[+] [-] intrasight|2 years ago|reply
If that's the definition (and I agree that it is) then 90% of my code is low code, as that's how much is XML, XSLT, and SQL. In C# .NET 8, another 5% is Linq which is a DSL that I consider low-code.
I have friends who work for a company that sells a million dollar low-code data platform. Business is good.
[+] [-] sremani|2 years ago|reply
[+] [-] TekMol|2 years ago|reply
Security
You get something that works. But how do you know there is no way to:
1: Alter the code from the outside
2: Access parts of the DB one is not supposed to access
Those can only be avoided by a programmer who knows about all the weird edge cases that might lead to 1 or 2 and how to write a complex system in a way that is structured to make bugs unlikely.
[+] [-] Jtsummers|2 years ago|reply
[+] [-] wonderwonder|2 years ago|reply
[+] [-] icoder|2 years ago|reply
[+] [-] carl_sandland|2 years ago|reply
[+] [-] TedDallas|2 years ago|reply
[+] [-] wizofaus|2 years ago|reply
[+] [-] rangledangle|2 years ago|reply
Then you sit there like an idiot dragging blocks around when you could have just asked GPT to bust it out in code in seconds.
They're so bad for source control and documentation, too.