9 ms·

When No-Code Stops Scaling (2020)

95 points by andrewedstrom 4y ago

honkycat 4y ago
One thing I was thinking about today with low-code or node-based programming languages is you miss a really important organizational tool: directories and files. This is specifically in the context of Unreal Blueprints. Files let you organize, group, and provide context to things in an intuitive outline-like way.
- maximus-decimus 4y ago
  You also lose GIT for version controlling, visual studio code as you IDE, Sonar for "low-code" smells, testing frameworks.
dataminded 4y ago
I've been around when these tools are being recommended or trialed -- the champion is never someone that understands anything about writing code. It is a way to reduce labor costs by getting Product Managers, Project Managers, Business folks and QA to generate code. I have never seen this work out.
- spoonjim 4y ago
  It is a very common way these days to deliver enough barebones functionality to get enough money to then hire a team to build the product. For example, you are selling a service that monitors for mentions of your social media account. You start with something that looks like a web app but is actually just an Airtable form that sends you an email, and you do the service manually by just Googling their social media handles every day. Once you get enough customers you then raise money to go actually build the web app.
jbmsf 4y ago
I was recently involved in evaluating a no-code UI toolkit. It did what it said it would, but did not (could not) solve certain key business logic problems (mostly related to domain-specific authorization). When we told people: we're happy for you to use this tool as long as you also write as something else that solves this necessary business problem, it took a lot of wind out of the sails. The hard stuff is still hard.
chihuahua 4y ago
Microsoft Dynamics tries to be a no-code platform (although you can add DLLs if you want to) and it's a nightmare. Your entire app is built into a giant XML file. It can take 45 minutes for this XML to be imported. In the repo, the XML is taken apart into thousands of small XML files. Any change to the app has to be done as follows: 1. build the giant XML file 2. import it into the platform 3. make the change (e.g. update a form or database column) 4. export as XML 5. shred it into thousands of little XML files Then you discover that one simple change in the app has turned into dozens of changes in XML files. And you have to figure out which of those changes to include in your commit. If you guess wrong, then unpredictable things can happen. If you're tempted to bypass all this by just editing the XML directly - sometimes it works, and sometimes the whole thing is deemed invalid, which you discover when importing it and you get an extremely unhelpful error message. The original idea was that you can define a data model, forms, and some business logic in a no-code manner. But it's a nightmare when you have a team of software developers working on an app.
- jksmith 4y ago
  Oh lordy, this is waking up some bad memories of using Dynamics for a huge project. As a team of 50, we started having to extend the crap out of it with c#, which made me question the use of the tool in the first place. So we called in an expert, who proceeded to tell up that if you didn't stay as close out of the box as you could with as little c# customization as possible, then we'd run into problems, which of course was the issue. That was in 2015, and the tool may have gotten better, but at the time, it was only capable of some basic crud applications, along with some pretty good interop with msft office. Point is, if it's a no/low code solution, the whole solution ultimately better be in the box. Otherwise you're screwed. So how do you come up with a uniquely competitive product from no/low code if the whole solution must already essentially be in the box? Maybe the best use case is internal IT needs.
  - pjmlp 4y ago
    This is typical enterprise stuff, Sitecore, SharePoint, SAP, LifeRay, AEM, .... Out of the box they are always very generic and then it is expected that a team of consultants, certified from agencies with vendor partnership, drop in to perform the actual customization.
chupchap 4y ago
The biggest no-code app I see in companies is Excel. It doesn't matter what you feel about it. If the data can fit an xlsx, it will be an excel sheet with macro.
- Larrikin 4y ago
  Are there any good examples of these amazing excel files that get passed around in companies? Nearly all examples I've seen are toy examples from college, simple imports of large csv files with some graphs added, or rarely interesting projects where someone creates a work of art with the cells. Friends and colleagues seem to manipulate data using tools like panda, R, or even Power Bi.
  - sandermvanvliet 4y ago
    I used to work in a team for a risk management department of a large bank. The excel sheets that the modellers were coming up with were pretty, shall we say, interesting. They basically built the app we were supposed to be building… but in Excel and then handed us the file saying “Here’s the spec” It worked quite well actually
    - tsm 4y ago
      I had this exact same experience working as a dev for a property insurance startup
  - phonon 4y ago
    https://people.engr.ncsu.edu/ermurph3/papers/icse-seip-15.pdf https://people.engr.ncsu.edu/ermurph3/papers/icse-seip-15.pd... https://github.com/SheetJS/enron_xls https://github.com/SheetJS/enron_xls
  - squeaky-clean 4y ago
    Those sorts of Excel projects generally aren't available in open source (or source-readable) projects. My first "real" programming job was to convert an Excel based report into one done with a general purpose programming language (we chose Python) because the reports were taking hours to generate in Excel and each report file was over a gigabyte in size. If it were simple static reports it would probably have been easy, but minor modifications were necessary every week, and the analytics team was terrible at conveying what was actually required without actually doing it in the excel, so management decided our program had to generate a more optimized version of the original Excel file as output to give to the analytics team to then work on. After like 3 months of work on this, I figured out how to just write a tiny python script to remove the unnecessary data from their excel files. It made it so they could open it on their cheaper laptops without grinding to a halt and generate the modified report in few minutes. And we didn't have to try to replicate an Excel formula structure that had been iterated on for over 5 years into python, and our team was moved to better tasks. I've also worked on complex language localization projects that probably would have been most optimally handled by a database connected application, but it's way easier to send an Excel file to contracted translators, so that's what we used. I've heard other horror stories from friends who work in finance. But they work, so whatever.
jv22222 4y ago
I've watched a lot of folks try to build a new product with no code tools, and when they want to add any kind of important feature for their use case... they have to learn how to code.
swyx 4y ago
> Currently, the supply of no-code developers and agencies is far greater than the demand. Anecdotally, I'd estimate in the high hundreds or low thousands of entities explicitly marketing themselves for this service. Then when it comes to ones who've worked on apps that have scaled 2-10x farther than yours (assuming you have a few thousand rows in your primary database table), there are far fewer. Most of the freelancers experience is centered around prototyping. All of these variables mean you'll be quoted in the range of ~$150+/hr for these freelancers. > Now looking at a code-based developer (like one who builds apps with Node or Rails apps), you can hire great ones for $50-100/hr. This is simply because there are millions of developers out there. this is the first time i've ever heard someone argue that its easier to hire normal developers than nocode developers. made me seriously question the piece.
- mrsuprawsm 4y ago
  I completely agree with the assertion that it's easier to hire normal devs vs no-code devs. I used to work at a company building one of the bigger low-code platforms (Mendix). Lots of our platform was "dogfooded", i.e. built in Mendix itself. Control plane apps, that kind of thing. This was a very bad idea for many reasons, but one major problem was hiring developers to work on it. There were simply very few competent specialized Mendix developers available on the market. The really good ones (that you wanted to hire) all became contractors earning >$150/hr. The other devs on the market were very junior. The alternative was to train up our own regular developers to use our low-code platform. But that didn't work either, because your average Java/Python dev recognized that low-code was a career dead-end, and didn't want to learn it.
gervwyk 4y ago
We’re building lowdefy: https://github.com/lowdefy/lowdefy https://github.com/lowdefy/lowdefy A low-code tool that let’s you build web apps using yaml. In v4, you config is run in a lightweight nextjs app, so should scale as well as nextjs for the most part. A lot of the issues that people are talking about in this thread have been address, mostly because with lowdefy we’ve focused on making the schema easy to read, write and understand. Currently we write all our apps by hard coding the yaml, and it’s scaling really well in our team. For writing apps in yaml, you get advantages like: - Apps follow a structured schema, thus easy to pick up where others left off. - Nothing is hidden in a GUI. You can copy, paste, find, replace, review changes, duplicate repos, etc. - Create and manage apps with code, develop scripts, like automating app updates. - YAML / JSON files work with all dev tools, devs are more efficient when they use their favourite tools. With Lowdefy v4 you can extend blocks, operators, actions, connections, adapters and providers with plugins, because sometimes custom code is the right solution. We’ve built enterprise level CRM and MRP systems using Lowdefy and our clients love how fast we ship features that they need in their business processes. It's really working well for our small team!
- GrumpyNl 4y ago
  There will always be that edge case where the low-code is not sufficient, that's where the problems start.
- mhitza 4y ago
  Greenspun's tenth rule seems applicable here [0] > Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. I write a lot of Ansible playbooks (yaml as well), been doing that for almost 10 years and I still have to jump to the reference manual. YAML DSLs are a pain to work with. Jetbrains software might have a plugin for GitHub Actions, Ansible(, and what have you), etc but that only makes slightly bearable. I think you might be to close to the core of the project to see that YAML without some autocomplete (intelisense) support is a though environment to work in. [0] https://github.com/lowdefy/lowdefy-example-case-management/blob/main/requests/fetch_tickets.yaml https://github.com/lowdefy/lowdefy-example-case-management/b...
_pdp_ 4y ago
In my opinion, low-code or no-code cannot be easily used as a general purpose solution. It is suitable for niche problem domains where some basic plumbing can be organised in basic logical workflows. For anything advance it is best to use a proper programming languages. Originally when I was designing the low-code solution for our security platform, I wanted it to be as generic as possible. Through trial and error I found out that such a solution is never going to succeed. Similarly some programming languages are better in some problem domains than others. You just need to know which tools to use.
- astrobe_ 4y ago
  From a 30.000ft view, this "no-code" thing looks like those "4th generation" RAD languages. They let you do what they were designed to do easy and quick, but the barrier around their scope was tall, specially for the "casual developers", their primary audience.
kkfx 4y ago
The issue is not technical per se: the issue is the bad evolution of IT toward a net separation of users: - programmers on one side - users, powerless, and hopefully ignorant that can't work. Any net separation can't work in practice. Specialization is needed for commerce, a bit of specialization is needed in practice because we profit from division of labor since some are more skilled in something while others in something else but not without all parties knowing a bit the so called big picture. That was in IT history the original desktop vision from Xerox to Symbolics passing through Bell Labs. Some, more skilled design desktops, their operating systems, others are users-programmers so not skilled enough nor interested in system-level development but soft-skilled enough to profit from proper end-user programming systems they got from the more skilled ones. That's the real "no code of the future", witch is actually from the past, witch have live today with Emacs for instance, playing with Lego-bricks "visual" tools, graphs, various modern UIs is just the proof that the elogium of ignorance and division into watertight compartments wanted by modern economic-driven management do not work properly and make bigger costs for bad outcomes while stating the contrary. No ML tool can solve that. We just need to ADMIT that for 30+years we have followed bad ideas and that originals one was the real solution, time to go back in time starting from now.
bilalq 4y ago
I've said this before, but the biggest issue with no/low code solutions is how they get abused. One of my past comments on HN: > 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. I get the appeal of how it seems easier to train people with business domain expertise on how to be no-code devs than it is to translate requirements to an engineering team or wait an indefinite amount of time for a dev team to prioritize work. But until no/low code solutions start focusing on how to maintain and operate the apps users build, they'll continue to be a landmine.
- CactusOnFire 4y ago
  To hop on the maintainability point: The same is true for "High-code" solutions. If you want the ticket done quick and dirty, it'll be done in a quarter of the time. But good luck ever iterating on it with additional features.
- q-big 4y ago
  > I get the appeal of how it seems easier to train people with business domain expertise on how to be no-code devs than it is to translate requirements to an engineering team Why do you think this is the case?
johnnyb_61820 4y ago
For those looking for more general reasons why "No Code" works for some tasks but doesn't scale (i.e., to present to a boss), I did an article series on No Code: https://mindmatters.ai/t/no-code-software/ https://mindmatters.ai/t/no-code-software/ Additionally, as an anecdote, I've seen organizations get burned on the security side because they had people who knew nothing about web security trying to build apps.
sirwhinesalot 4y ago
I think the only real advantage of no-code/low-code stuff is the lower friction to get started, but these tools invariably suck. I grew up with Game Maker (before Studio) and just having clear icons to add events and draw sprites and such made things so much easier to learn. That to me should be the focus. But from what I've seen these tools are mostly vendor-lock-in scams for non-coders. Sad.
kclay 4y ago
We have been evaluating how to scale our company (software agency) to be able to quickly build out mvps for some of our projects. The topic of no-code has come up and the one product named Unqork[1] has been mentioned to us. Has anyone had success with these solutions, if so what type of projects have this no-code paradigm excelled at? [1] https://www.unqork.com/ https://www.unqork.com/
- mbrodersen 4y ago
  Run don’t walk away from no-code tools. Seriously. I have never seen or heard of a case where no-code tools increased productivity long term. Instead, hire good developers who knows how to be more productive with real production languages.
- gervwyk 4y ago
  Check out Lowdefy. https://github.com/lowdefy/lowdefy https://github.com/lowdefy/lowdefy Co-Founder of Lowdefy here. We're having great success with it as a software agency, it really scales well with projects because you can organise files and folders the way you like, and do code review because you are working with a app schema that is easy to read, write and understand. Which enables all the advantages of coding as well as low-code.
  - kclay 4y ago
    An open source solution, thanks will check this out.
- mhitza 4y ago
  Have you invested into building an internal starterkit that includes all the parts common among all webapps, on a stack you have expertise in? Or pick an existing starter kit on the market and base all your MVP projects on that?
  - kclay 4y ago
    Yeah we have a few components we are using across projects and are going to start expanding that out throughout our stack.
ecshafer 4y ago
I was at one point on a team building out infra integration with Appian, which touts itself as a low-code / no-code platform. The sales pitch is the no-code example which executives really love, and the pitch is that they can get some "business minded people" to write the "low-code". But the complexity was enough that we ended up throwing a bunch of junior software developers and hiring consultants for it, so you ended up with something like 25 software developers on a "low code" platform. The "low code" option, which isn't really less code than just writing it in a terse language like python (so really only code compared to java). So for this company moving to Appian, we ended up writing a ton of integration work in Java, and tons of AWS services. Then with a bunch of custom, vendor locked, appian language for their platform. And in the end we could have saved money if we had just rewritten the whole platform on AWS for our own use case using just a rules engine in postgres and some service.
- no_butterscotch 4y ago
  To your experience I wonder if some of these low-code/no-code platforms are succeeding because of successful salesmanship and networking rather than technical merit. Similar to how vendor A can wine and dine the right person from firm B to get the firm to adopt vendor A's tech, rather than having the right internal people vet the solution. It isn't the developers that are pitched. It is the people over the heads of the developers, this seems to be crucial.
  - kitd 4y ago
    Just like the 4GL products of the 1980s. That and knowing which C-suite exec to target.
  - marvin 4y ago
    Microsoft's SharePoint went through this exact same routine ten years ago. The salespeople loved it, the customers bought it and the tech folks trying to implement the customer's needs were tearing out their hair and delivering super expensive and super terrible solutions.
    - 4y ago
kagia 4y ago
Oddly specific numbers, 50k records take 5minutes? What was the authors methodology?
- jkcorrea 4y ago
  I assume they're referring to the 50k record limit & 5 req/s Airtable has

95 points by andrewedstrom 4y ago

One thing I was thinking about today with low-code or node-based programming languages is you miss a really important organizational tool: directories and files. This is specifically in the context of Unreal Blueprints. Files let you organize, group, and provide context to things in an intuitive outline-like way.

maximus-decimus 4y ago
You also lose GIT for version controlling, visual studio code as you IDE, Sonar for "low-code" smells, testing frameworks.

dataminded 4y ago

I've been around when these tools are being recommended or trialed -- the champion is never someone that understands anything about writing code. It is a way to reduce labor costs by getting Product Managers, Project Managers, Business folks and QA to generate code. I have never seen this work out.

spoonjim 4y ago
It is a very common way these days to deliver enough barebones functionality to get enough money to then hire a team to build the product. For example, you are selling a service that monitors for mentions of your social media account. You start with something that looks like a web app but is actually just an Airtable form that sends you an email, and you do the service manually by just Googling their social media handles every day. Once you get enough customers you then raise money to go actually build the web app.

jbmsf 4y ago

I was recently involved in evaluating a no-code UI toolkit. It did what it said it would, but did not (could not) solve certain key business logic problems (mostly related to domain-specific authorization). When we told people: we're happy for you to use this tool as long as you also write as something else that solves this necessary business problem, it took a lot of wind out of the sails. The hard stuff is still hard.

chihuahua 4y ago

Microsoft Dynamics tries to be a no-code platform (although you can add DLLs if you want to) and it's a nightmare. Your entire app is built into a giant XML file. It can take 45 minutes for this XML to be imported. In the repo, the XML is taken apart into thousands of small XML files. Any change to the app has to be done as follows: 1. build the giant XML file 2. import it into the platform 3. make the change (e.g. update a form or database column) 4. export as XML 5. shred it into thousands of little XML files Then you discover that one simple change in the app has turned into dozens of changes in XML files. And you have to figure out which of those changes to include in your commit. If you guess wrong, then unpredictable things can happen. If you're tempted to bypass all this by just editing the XML directly - sometimes it works, and sometimes the whole thing is deemed invalid, which you discover when importing it and you get an extremely unhelpful error message. The original idea was that you can define a data model, forms, and some business logic in a no-code manner. But it's a nightmare when you have a team of software developers working on an app.

jksmith 4y ago
Oh lordy, this is waking up some bad memories of using Dynamics for a huge project. As a team of 50, we started having to extend the crap out of it with c#, which made me question the use of the tool in the first place. So we called in an expert, who proceeded to tell up that if you didn't stay as close out of the box as you could with as little c# customization as possible, then we'd run into problems, which of course was the issue. That was in 2015, and the tool may have gotten better, but at the time, it was only capable of some basic crud applications, along with some pretty good interop with msft office. Point is, if it's a no/low code solution, the whole solution ultimately better be in the box. Otherwise you're screwed. So how do you come up with a uniquely competitive product from no/low code if the whole solution must already essentially be in the box? Maybe the best use case is internal IT needs.
- pjmlp 4y ago
  This is typical enterprise stuff, Sitecore, SharePoint, SAP, LifeRay, AEM, .... Out of the box they are always very generic and then it is expected that a team of consultants, certified from agencies with vendor partnership, drop in to perform the actual customization.

chupchap 4y ago

The biggest no-code app I see in companies is Excel. It doesn't matter what you feel about it. If the data can fit an xlsx, it will be an excel sheet with macro.

Larrikin 4y ago
Are there any good examples of these amazing excel files that get passed around in companies? Nearly all examples I've seen are toy examples from college, simple imports of large csv files with some graphs added, or rarely interesting projects where someone creates a work of art with the cells. Friends and colleagues seem to manipulate data using tools like panda, R, or even Power Bi.
- sandermvanvliet 4y ago
  I used to work in a team for a risk management department of a large bank. The excel sheets that the modellers were coming up with were pretty, shall we say, interesting. They basically built the app we were supposed to be building… but in Excel and then handed us the file saying “Here’s the spec” It worked quite well actually
  - tsm 4y ago
    I had this exact same experience working as a dev for a property insurance startup
- phonon 4y ago
  https://people.engr.ncsu.edu/ermurph3/papers/icse-seip-15.pdf https://people.engr.ncsu.edu/ermurph3/papers/icse-seip-15.pd... https://github.com/SheetJS/enron_xls https://github.com/SheetJS/enron_xls
- squeaky-clean 4y ago
  Those sorts of Excel projects generally aren't available in open source (or source-readable) projects. My first "real" programming job was to convert an Excel based report into one done with a general purpose programming language (we chose Python) because the reports were taking hours to generate in Excel and each report file was over a gigabyte in size. If it were simple static reports it would probably have been easy, but minor modifications were necessary every week, and the analytics team was terrible at conveying what was actually required without actually doing it in the excel, so management decided our program had to generate a more optimized version of the original Excel file as output to give to the analytics team to then work on. After like 3 months of work on this, I figured out how to just write a tiny python script to remove the unnecessary data from their excel files. It made it so they could open it on their cheaper laptops without grinding to a halt and generate the modified report in few minutes. And we didn't have to try to replicate an Excel formula structure that had been iterated on for over 5 years into python, and our team was moved to better tasks. I've also worked on complex language localization projects that probably would have been most optimally handled by a database connected application, but it's way easier to send an Excel file to contracted translators, so that's what we used. I've heard other horror stories from friends who work in finance. But they work, so whatever.

jv22222 4y ago

I've watched a lot of folks try to build a new product with no code tools, and when they want to add any kind of important feature for their use case... they have to learn how to code.

swyx 4y ago

> Currently, the supply of no-code developers and agencies is far greater than the demand. Anecdotally, I'd estimate in the high hundreds or low thousands of entities explicitly marketing themselves for this service. Then when it comes to ones who've worked on apps that have scaled 2-10x farther than yours (assuming you have a few thousand rows in your primary database table), there are far fewer. Most of the freelancers experience is centered around prototyping. All of these variables mean you'll be quoted in the range of ~$150+/hr for these freelancers. > Now looking at a code-based developer (like one who builds apps with Node or Rails apps), you can hire great ones for $50-100/hr. This is simply because there are millions of developers out there. this is the first time i've ever heard someone argue that its easier to hire normal developers than nocode developers. made me seriously question the piece.

mrsuprawsm 4y ago
I completely agree with the assertion that it's easier to hire normal devs vs no-code devs. I used to work at a company building one of the bigger low-code platforms (Mendix). Lots of our platform was "dogfooded", i.e. built in Mendix itself. Control plane apps, that kind of thing. This was a very bad idea for many reasons, but one major problem was hiring developers to work on it. There were simply very few competent specialized Mendix developers available on the market. The really good ones (that you wanted to hire) all became contractors earning >$150/hr. The other devs on the market were very junior. The alternative was to train up our own regular developers to use our low-code platform. But that didn't work either, because your average Java/Python dev recognized that low-code was a career dead-end, and didn't want to learn it.

gervwyk 4y ago

We’re building lowdefy: https://github.com/lowdefy/lowdefy https://github.com/lowdefy/lowdefy A low-code tool that let’s you build web apps using yaml. In v4, you config is run in a lightweight nextjs app, so should scale as well as nextjs for the most part. A lot of the issues that people are talking about in this thread have been address, mostly because with lowdefy we’ve focused on making the schema easy to read, write and understand. Currently we write all our apps by hard coding the yaml, and it’s scaling really well in our team. For writing apps in yaml, you get advantages like: - Apps follow a structured schema, thus easy to pick up where others left off. - Nothing is hidden in a GUI. You can copy, paste, find, replace, review changes, duplicate repos, etc. - Create and manage apps with code, develop scripts, like automating app updates. - YAML / JSON files work with all dev tools, devs are more efficient when they use their favourite tools. With Lowdefy v4 you can extend blocks, operators, actions, connections, adapters and providers with plugins, because sometimes custom code is the right solution. We’ve built enterprise level CRM and MRP systems using Lowdefy and our clients love how fast we ship features that they need in their business processes. It's really working well for our small team!

GrumpyNl 4y ago
There will always be that edge case where the low-code is not sufficient, that's where the problems start.
mhitza 4y ago
Greenspun's tenth rule seems applicable here [0] > Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. I write a lot of Ansible playbooks (yaml as well), been doing that for almost 10 years and I still have to jump to the reference manual. YAML DSLs are a pain to work with. Jetbrains software might have a plugin for GitHub Actions, Ansible(, and what have you), etc but that only makes slightly bearable. I think you might be to close to the core of the project to see that YAML without some autocomplete (intelisense) support is a though environment to work in. [0] https://github.com/lowdefy/lowdefy-example-case-management/blob/main/requests/fetch_tickets.yaml https://github.com/lowdefy/lowdefy-example-case-management/b...

_pdp_ 4y ago

In my opinion, low-code or no-code cannot be easily used as a general purpose solution. It is suitable for niche problem domains where some basic plumbing can be organised in basic logical workflows. For anything advance it is best to use a proper programming languages. Originally when I was designing the low-code solution for our security platform, I wanted it to be as generic as possible. Through trial and error I found out that such a solution is never going to succeed. Similarly some programming languages are better in some problem domains than others. You just need to know which tools to use.

astrobe_ 4y ago
From a 30.000ft view, this "no-code" thing looks like those "4th generation" RAD languages. They let you do what they were designed to do easy and quick, but the barrier around their scope was tall, specially for the "casual developers", their primary audience.

kkfx 4y ago

The issue is not technical per se: the issue is the bad evolution of IT toward a net separation of users: - programmers on one side - users, powerless, and hopefully ignorant that can't work. Any net separation can't work in practice. Specialization is needed for commerce, a bit of specialization is needed in practice because we profit from division of labor since some are more skilled in something while others in something else but not without all parties knowing a bit the so called big picture. That was in IT history the original desktop vision from Xerox to Symbolics passing through Bell Labs. Some, more skilled design desktops, their operating systems, others are users-programmers so not skilled enough nor interested in system-level development but soft-skilled enough to profit from proper end-user programming systems they got from the more skilled ones. That's the real "no code of the future", witch is actually from the past, witch have live today with Emacs for instance, playing with Lego-bricks "visual" tools, graphs, various modern UIs is just the proof that the elogium of ignorance and division into watertight compartments wanted by modern economic-driven management do not work properly and make bigger costs for bad outcomes while stating the contrary. No ML tool can solve that. We just need to ADMIT that for 30+years we have followed bad ideas and that originals one was the real solution, time to go back in time starting from now.

bilalq 4y ago

I've said this before, but the biggest issue with no/low code solutions is how they get abused. One of my past comments on HN: > 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. I get the appeal of how it seems easier to train people with business domain expertise on how to be no-code devs than it is to translate requirements to an engineering team or wait an indefinite amount of time for a dev team to prioritize work. But until no/low code solutions start focusing on how to maintain and operate the apps users build, they'll continue to be a landmine.

CactusOnFire 4y ago
To hop on the maintainability point: The same is true for "High-code" solutions. If you want the ticket done quick and dirty, it'll be done in a quarter of the time. But good luck ever iterating on it with additional features.
q-big 4y ago
> I get the appeal of how it seems easier to train people with business domain expertise on how to be no-code devs than it is to translate requirements to an engineering team Why do you think this is the case?

johnnyb_61820 4y ago

For those looking for more general reasons why "No Code" works for some tasks but doesn't scale (i.e., to present to a boss), I did an article series on No Code: https://mindmatters.ai/t/no-code-software/ https://mindmatters.ai/t/no-code-software/ Additionally, as an anecdote, I've seen organizations get burned on the security side because they had people who knew nothing about web security trying to build apps.

sirwhinesalot 4y ago

I think the only real advantage of no-code/low-code stuff is the lower friction to get started, but these tools invariably suck. I grew up with Game Maker (before Studio) and just having clear icons to add events and draw sprites and such made things so much easier to learn. That to me should be the focus. But from what I've seen these tools are mostly vendor-lock-in scams for non-coders. Sad.

kclay 4y ago

We have been evaluating how to scale our company (software agency) to be able to quickly build out mvps for some of our projects. The topic of no-code has come up and the one product named Unqork[1] has been mentioned to us. Has anyone had success with these solutions, if so what type of projects have this no-code paradigm excelled at? [1] https://www.unqork.com/ https://www.unqork.com/

mbrodersen 4y ago
Run don’t walk away from no-code tools. Seriously. I have never seen or heard of a case where no-code tools increased productivity long term. Instead, hire good developers who knows how to be more productive with real production languages.
gervwyk 4y ago
Check out Lowdefy. https://github.com/lowdefy/lowdefy https://github.com/lowdefy/lowdefy Co-Founder of Lowdefy here. We're having great success with it as a software agency, it really scales well with projects because you can organise files and folders the way you like, and do code review because you are working with a app schema that is easy to read, write and understand. Which enables all the advantages of coding as well as low-code.
- kclay 4y ago
  An open source solution, thanks will check this out.
mhitza 4y ago
Have you invested into building an internal starterkit that includes all the parts common among all webapps, on a stack you have expertise in? Or pick an existing starter kit on the market and base all your MVP projects on that?
- kclay 4y ago
  Yeah we have a few components we are using across projects and are going to start expanding that out throughout our stack.

ecshafer 4y ago

I was at one point on a team building out infra integration with Appian, which touts itself as a low-code / no-code platform. The sales pitch is the no-code example which executives really love, and the pitch is that they can get some "business minded people" to write the "low-code". But the complexity was enough that we ended up throwing a bunch of junior software developers and hiring consultants for it, so you ended up with something like 25 software developers on a "low code" platform. The "low code" option, which isn't really less code than just writing it in a terse language like python (so really only code compared to java). So for this company moving to Appian, we ended up writing a ton of integration work in Java, and tons of AWS services. Then with a bunch of custom, vendor locked, appian language for their platform. And in the end we could have saved money if we had just rewritten the whole platform on AWS for our own use case using just a rules engine in postgres and some service.

no_butterscotch 4y ago
To your experience I wonder if some of these low-code/no-code platforms are succeeding because of successful salesmanship and networking rather than technical merit. Similar to how vendor A can wine and dine the right person from firm B to get the firm to adopt vendor A's tech, rather than having the right internal people vet the solution. It isn't the developers that are pitched. It is the people over the heads of the developers, this seems to be crucial.
- kitd 4y ago
  Just like the 4GL products of the 1980s. That and knowing which C-suite exec to target.
- marvin 4y ago
  Microsoft's SharePoint went through this exact same routine ten years ago. The salespeople loved it, the customers bought it and the tech folks trying to implement the customer's needs were tearing out their hair and delivering super expensive and super terrible solutions.
  - 4y ago

kagia 4y ago

Oddly specific numbers, 50k records take 5minutes? What was the authors methodology?

jkcorrea 4y ago
I assume they're referring to the 50k record limit & 5 req/s Airtable has