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.<p>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.
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:<p>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<p>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.<p>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.<p>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.
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:<p>> 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?<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.<p>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.
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.
The issue is not technical per se: the issue is the bad evolution of IT toward a net separation of users:<p>- programmers on one side<p>- users, powerless, and <i>hopefully</i> ignorant<p>that can't work. Any net separation can't work in practice. Specialization is needed for commerce, <i>a bit of</i> 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.<p>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 <i>proper end-user programming systems</i> they got from the more skilled ones.<p>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.
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.
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:<p><a href="https://mindmatters.ai/t/no-code-software/" rel="nofollow">https://mindmatters.ai/t/no-code-software/</a><p>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.
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.<p>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.
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.
We’re building lowdefy: <a href="https://github.com/lowdefy/lowdefy" rel="nofollow">https://github.com/lowdefy/lowdefy</a><p>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.<p>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.<p>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.<p>With Lowdefy v4 you can extend blocks, operators, actions, connections, adapters and providers with plugins, because sometimes custom code is the right solution.<p>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!
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.
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).<p>When we told people: we're happy for you to use this tool <i>as long as</i> you also write as something else that solves this necessary business problem, it took a lot of wind out of the sails.<p>The hard stuff is still hard.
> 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.<p>> 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.<p>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.
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.<p>This is specifically in the context of Unreal Blueprints.<p>Files let you organize, group, and provide context to things in an intuitive outline-like way.
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?<p>[1] <a href="https://www.unqork.com/" rel="nofollow">https://www.unqork.com/</a>