I suspect you are talking at cross purposes. You are suggesting no-code first on a micro timescale. For prototyping. That seems like a solid suggestion and use of resources.

But from the GP, I read a statement on the macro scale. No-code can't codify turn-key pluggable building blocks until the problem spaces of those blocks have been thoroughly explored by code solutions, and a small number of "winning" configurations identified.

Sure, those blocks can be plugged together to prototype "novel" line of business "problems", but I think there's a disconnect in the kind of problem spaces you are talking about.

The "solved" problems that the no-code widgets represent still need to be solved by code first. And expectations continue to move.

We have a different definition of no-code, I think. I wasn't including any tools that don't offer generic enough primitives to build an arbitrary business process.

If we're reducing no-code to "things that have been written in code first, that can then be plugged together by the no-code user", then we're talking about libraries with a visual designer on top.

I think you’re thinking higher level than the other side of this conversation thread? Maybe a better way to describe it is that you couldn’t build something like Retool (which is super cool, I like it) without a lot of prior formative design around CRUD and repeatable consistent model handling even across very different data stores and dealing with double-sent commits and the like.

No-code approaches need to be prescriptive about how they deal with systems and it takes a long time to get to the point where we know how to do that in a way that won’t infuriate people.

I guess here is where "no-code" as a big-tent term breaks down.

Most of the targeted products in the space seem like they can be expressed as "I know how to ___, but I don't want to ___" (f.ex. Retool looks like: write a query, write a UI). Which, yes, trade opinionated design for design time efficiency, which is most of their value.

On the other hand, you also have no-code frameworks which are icons and a designer wrapped around primitives that afford you enough access to control flow and variables to build anything you could code. E.g. Node-RED, UiPath, or Power Automate. Which don't need to be very opinionated, because their entire purpose is to be a build-anything toolbox.

So it's probably more useful to differentiate focused no-code products from general-purpose ones.

> Node-RED, UiPath, or Power Automate.

All of which have teams of developers behind them, maintaining the code that underly those control flow constructs and form the higher level abstractions that the low code user interacts with.

Yeah - where I've seen those things used for more than trivial things, there's usually a developer in the org who's handling the places where they fall over.

UiPath (and similar) as a "no code" solution is a bit of a joke (on those that don't know any better). Don't get me wrong, I think it's a good application for automating processes or certain types of jobs, but a lot of coding has to go into it. Often you are typing lots of VB.NET or C# code into boxes.

What's often really going on, is often "packaged libraries" that you add to do a task, then lots of typing of sort of "glue code" in boxes to get them to work together. Which can lead to getting bit in the butt with the problems of "no code visual programming", where there is boxes on top of boxes hiding stuff and potential troubleshooting headaches.

Often, the team needs a "real programmer" or close to it, that can handle the heavy lifting, troubleshooting, or custom solutions.

Sure, your no code system can be Turing complete. Lots of things are accidentally Turing complete. But at that point, aren't you just coding with a different interface but all the same problems and complexity? And (as argued already elsewhere in the thread) none of the tools and support...

I agree that "arbitrary business process" is a smaller target. But it's one that grows over time (see GP comment) to include more and more "solved problems" that were solved by lots and lots of code.

>So essentially, the company gets version 2 of the code, at the cost of 1x user time + 1x developer time. Instead of version 2 of the code, in 2x developer time, which is too expensive and never happens.

Not sure why, but in my experience the difference has been closer to 1x user time + 1x developer time <> 4x developer time.

I believe empowering a customer to think along — be pushed to their limits, even — within the boundaries of a system's technical/business domain _from the very start_ is likely to dramatically improve a system's design.

From a technical perspective it may not be architected well, but in terms of user <> business fit it probably will be.

SQL is no/low-code compared to using a low-level database like BDB for a given level of power. And yet it's much simpler for most use cases.

By the same token, C is low-code compared to assembler, Python is low-code compared to C, and Steel Bank Common Lisp is low-code compared to Python.

Using the same kind of reasoning, JavaScript is a framework and JQuery is no code. Or maybe React and Angular are no code and JQuery is low code? We basically need a firm, objective basis for determining what a thing is. The question is: what is it?

> My experience has been that actual code is always superior* to no-code, because no-code is always more complex

Yes, usually an order of magnitude more complex, even.

Maintenance is a big issue when you are using a no-code system to create another system which someone else will use (e.g. to create a business application).

But if you are using a no-code system to create an artefact (e.g. to wrangle data into a new format) then that issue isn't so relevant.

I used to think this as well, that No Code was not a real development to production level option. I have very much been proven wrong. I transition recently from 15+ years as a developer to contracting for a no code platform. Virtually everything a regular web dev can do in code can be done in no code. Sometimes its easier to do in code and sometimes it is much easier to do in no code so mileage may vary but no code is very much a mature technology now that can produce applications to the same scale as regular web 2.0 coded software.

I've been consulting in no-code platforms, in addition to writing actual code, for about 8 years. Producing something that works isn't the problem.

Maintaining it is.

The legacy codebases from this stuff are dumpster fires, because most of the tools are closed enough ecosystems that the companies supporting them have to reinvent every programming best practice from the last 30 years.

'Version control? Sure, that's a feature on our roadmap that we'll get to at some point...'

In addition to going back to the bad old days of limited-use, proprietary compiler problems. 'Oh, that bug? Yeah, just don't do that.'

Furthermore, unless you choose very carefully, you're playing right into vendor lock-in, and a lot of the people buying this stuff aren't technically proficient enough to realize that.

Once these companies hit the end of the easy growth ramp, and the industry turns into monetizing & squeezing existing customers, there's going to be migration pain on an Oracle scale.

Maintainability is always the issue, even for the things made from code.

What do you think will happen if the no-code platforms become open source?

Every general no code platform I've worked with has had an order of magnitude (sometimes, multiple) worse maintainability story than code alternatives.

And admittedly, maybe I've worked with a series of terrible ones, but I've also worked with a lot of popular ones that big enterprises are adopting.

As for open source, I'd say zero percent chance that happens, because no code solves problems developers don't have: (1) I want to write code, but I don't know how to code & (2) I need to integrate a lot of really boring, legacy, usually-Windows apps.

It's the "Why are there no polished open source desktop environments?" problem from the 90s, multiplied by ten.

Which I think is why you see what open source no-code tools do exist focus on web, because that's closer to what their developers are curious about.

Based on your experience would you be comfortable to list a few of the no-code tools to avoid when taking maintainability into account? Would be useful.

Names seems a bit specific, but it's easy enough to think in terms of basic software hygiene practices: things we expect our languages and their ecosystems to provide in traditional code these days.

Is the "code" serialized to a text readable format, for storage and parsing by other tools? Can I get a copy of that serialization? Can I regenerate the effective program from that serialization?

Are there methods for appropriate modularization and encapsulation?

Is there a coherent versioning strategy that allows for controlled updates, down through dependencies?

Can I check it into standard source control? And does it play nice with the expectations therein?

Basically: everything you were taught in undergrad for software engineering & at your first job

The biggest problem with the industry is that it's being sold to people who know none of that, or they're being told that doesn't really matter here, because this isn't code and thus doesn't need all that.

People who have maintained these systems know the level of pain is much worse than nearly any codebase. No code solutions that end up mission-critical can stay active for decades.

We have solutions from the 90s that, thank the heavens, I don’t have to work on them. If I did I would probably quit. But the business has to keep the thing chugging along, and it’s _very hard_ to get out of.

> no code is very much a mature technology now

How is "no code" a technology? Aren't there a variety of "no code" technologies?

I'd be interested to hear which ones you are seeing that can produce applications similar to ordinary software development! Like... it's probably not WordPress or SharePoint.

Unqork platform is pretty robust.

OK, but web development is an area that jerf would probably classify as "solved".

I like this idea, but does it work in praxtice?