Things we agree on: ignore everything no-code proponents say about their tools or capabilities

Things we disagree on: code before no code

My experience has been that actual code is always superior* to no-code, because no-code is always more complex. E.g. the no-code developer environment + code (in whatever designer form) + interpreter / runtime / libraries + any integrations + actual generated code.

Consequently, business critical functions should be in actual code, if it's an option.

So where and why to use no-code?

As a prototyping tool, no-code before code, because it inverts the pyramid (few developers, many users) by making users into prototyping developers, and it makes the best use of scarce resources (code developer time).

No-code written by users allows you to waste user time figuring out all the things that are typically missing in a business spec, without wasting developer time. Then, when they've figured out exactly what they want (because it works!), developers can come back and do exactly that.

This usually involves throwing away the no-code model when coding, because it's probably not going to be architected well, but does provide a concrete, tested, proven spec.

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.

* From a TCO, maintenance and reliability standpoint

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?

My first job out of university was working with a very large firm that bought into Computer Associates' product suite - including 4GL code generators such as Telon ("green-screen" generators) and Easytrieve (4GL report generators). From what I recall, we spent 90% of our time trying to work around the code generators to accomplish tasks, as opposed to simply using native CICS, which was difficult to master (hence the 4GL). I've since used a number of 4GL-type tools, and they've all had the same limitation in that the tail wags the dog, to use an old idiom. Quite fast and seemingly magical if you stay within the guardrails, but as soon as you veer off course (and unless you don't want any differentiators, you will) they quickly become far more onerous than hand-coding, plus lock you into their 'forced march': cost, upgrades, incompatibilities, and so on.

As an aside, it was a very interesting time to be a developer as we had a mix of youngsters (me), who were raised on personal computers, many people seasoned on mainframes/mid-range computers, plus a few "old-timers" who started coding in the 1950s without any formal training. Everyone had great stories, and I feel lucky to have been exposed to people firsthand who were some of the first programmers (and they universally thought everything above assembly language was 'cheating'). Their stories and perspectives have stayed with me throughout my career.

I knew a team that did 4GL on AS/400s (generating RP4 I think) and they were all about how superior their tool was and how terrible the Java team was in comparison and how they would never be out of a job. Within a couple years none were programmers any more as their tool was abandoned and they had no other programming skill.

Where did they come from, and where did they go? Business analysts that were given no-code tools, thought themselves the new-wave programmers, and then faded back into analyst/architecture roles?

The first time I encountered something that called itself "no-code" was when the internet portal I worked for (Remember those?) decided to offer a "webpage builder" for its users. I didn't work on it, but just looking at the limited webpages you could build with it, how all of those were basically just our best practices, and how the amount of code needed to support the builder was just massive compared to the code it generated, it was pretty clear to me that my job security wasn't threatened.

Every single solution like this has an edge, a limitation, and when you reach that edge, the answer is always "well, you can edit the code directly if you know what you're doing..."

It's exactly as you say, every solution like this can do the already mapped parts of programming, but they are fundamentally incapable of being used for the unmapped parts, the woods, the edges, the limits.

I remember my father coming home in the 80s from work with a book detailing an environment they built at the company he worked at for creating complete business systems by just configuring building blocks; no code at all. You modeled the data, modeled the screens, modeled the processes by picking options of screens covered in dropdowns and input fields: the end result was a working system. Sounds familiar? It was extremely close to Bubble with a different GUI. It worked until clients asked feature that were very hard or impossible to make and they add to add features or code extensions; after a while they noted that many projects were just extensions upon extensions. They ended up taking out the modeling part and use it like UML type of thing, but the no code was removed in favor of people writing it manually following the modeled parts.

Yup, this is a very old hype cycle. Seems that every bunch of years, the industry has to relearn it. Yes, they can be useful for some situations, but the limits close in fast, and soon you will have to deal with real logic, concurrency, etc, as well as product limitations, and vendor lock-in.

And there are multiple reasons that corps separate development tools from ordinary users. First is that it is a very short path until the project will encounter questions that require actual development training and expertise to get right - and there are 100 wrong ways to get it wrong, many of which will create real damage & business costs.

And the other perhaps best described by the exec who said (a few decades ago) that "I don't want to turn a great senior $200k analyst into a mediocre junior $35k BASIC programmer at the same cost".

So yeah, giving users such tools to hammer out prototypes to give better specs to developers ican work great, but thinking that the latest "no code" tool is the end of it is foolish.

COBOL. SQL. HyperCard. Visual Basic. Spreadsheets. Yeah, same song, next verse.

In some ways it's like AI, though. Once it succeeds (at what it can do), then it no longer is "no code", it's just it's own niche. (We don't think of SQL or spreadsheets as "no code" any more; we think of them as their own categories.)

I mean, spreadsheets are not nothing. They're useful for a segment of things. They didn't replace web programming or embedded real-time or machine learning, though.

I remember articles early on during the release of SQL that promoted it as a way to reduce the need for programmers because it would allow managers to access all the data they wanted through natural language. Things didn't really turn out that way.

I took a course in COBOL when I was in Unversity. The professor was in industry but taught one night class a semester.

He started the class by talking about how when he learned COBOL, they told him this would make developers obsolete because it would let managers build their own solution. In his experience, it made developers even more valuable because “give a manager five minutes with a codebase, give a developer a job for five years cleaning the mess up.”

As a software engineer, the business data my manager wants is basically in Jira and even if they provides a (supposedly) user-friendly UI, they also offers their powerful JQL. And at the end of the day, each times my manager wants something specific from Jira, he comes to me so that I can provide him with the right query. And he's supposed to have a technical background, so I guess it's even worse with non tech people.

I totally agree, and this jives with my feeling that no-code is an evolution or a codification of the best practices and principles "hammered out" as you say over the years by regular software development.

The Tao gave birth to machine language. Machine language gave birth to the assembler.

The assembler gave birth to the compiler. Now there are ten thousand languages.

Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.

But do not program in COBOL if you can avoid it.

- The Tao of Programming (1987)

I remember an ad in the programming rags of the 80's that ran for about a year. It advertised (from my memory) "no coding required! Just use our script interface!"

[No|Low] code platforms just breed a new class of consultants instead of empowering end users due to the simple fact that [no|low] code is still too technical.

> It just goes wrong when no-code advocates put the cart in front of the horse and make grandiose claims about replacing all developers or something

"no code" like most IT industry buzzwords over the last 70 years, is mostly bullshit but with a kernel of useful truth.

This!

The funny thing about no code is that after delving into it for 6 months as a non-technical person and realising its limitations it pushed me to start my code learning journey again.

It has its purpose for prototyping and some early validation but...

It gets expensive... it gets fragmented and you are closed down to one ecosystem (hello Bubble).

I hacked things together with airtable, Webflow and Zapier. It aggregated to hundreds of dollars per month in costs. I also found myself constantly trying to find some workarounds and in fact there are additional app extensions to Webflow that allow to create even basic functionality like search or multi-filters.

Long story short it has its place for specific purposes but even then I would still rather learn how to spin-off netlify or vercel and put a boiler plate with mailchimp online to test my hypothesis rather than mapping data strings in Zapier for as simple as form collection fields.

I though must thank no code for getting me back into code! I am still a newbie but I am enjoying every moment of my javascript journey (is it a masochistic thing to say considering all the frustration with bugs?)

+1

You just have to look at WordPress / Squarespace / Wix / Weebly / I forget the rest ... for examples of consumer-oriented platforms, however you define the term "consumer," that promise no coding needed for the average user - but you'll get a better result if it's built by a fluent developer who isn't constrained by the platform's conventions.

The brain is great at imagining stuff “we could build that, and you’d have this and that…”. And a lot of the time you can build it but it requires code.

Using a tool that avoids code always means either compromise or you are really coding but in an inefficient ui (eg building a budget app in excel)

COBOL never claimed to be "no code", but what it did claim was that it would significantly lower the level of training required to program. Which it absolutely did. Before compilers, you had to program in machine code which was extremely tedious and error prone and required a detailed understanding the microprocessor and computer architecture.

COBOL may seem clunky compared to modern languages, but the productivity improvement going from machine code to COBOL was likely larger than going from C++ to Python. COBOL have a bad reputation these days, but this is only because of how successful it was, leading it to still being used for mission-critical systems.

Well and having to maintain legacy code written by people who had received only little training.

COBOL isn't older than all of us!

Completely agree, and it makes me wonder if we are at the edge of standardization for many types of applications. The desktop, tablet, and mobile form factors and use cases are well understood. Best practices amongst these major platforms are in place. The cloud is maturing (litmus test for this is the reinvent seems to be less exciting each year). New form factors, like AR/VR, don’t have the market share for broad changes to development practices yet.

This seems true until one can generate code based on descriptions like GH Copilot can do. That’s a step towards structurally capable.

COBOL is code - it's not nocode.

It was sold as "basically English, so programmers are obsolete since everyone can write their own software". Which is pretty much the same pipe dream as "no code".

Yeah, if you look at it, it's designed after recipes, even more so than typical programming. It starts with a title of the module, then a data definition section (ingredients), and the the program section which is a numbered list of english phrases to be performed more or less in order.

The idea was to convert women who had been working _as_ computers, into programmers.

"Programmers" referring to engineers working with machine code and hardware architecture. People writing in high level languages where not considered "real programmers" back in the day, just like people writing in Python or JavaScript were not considered "real programmers" more recently.

But who you decide to call "real programmers" is of course beside the point. What is interesting is the raising of the abstraction level which happens with higher-level tools.

By the standards of the time when even macro assemblers weren't always available and programmers often had to do the translation to machine code manually, it was unlike code. It was even portable!

Have you met assembly?

well said!

I can say from our experience: we made more that 2000+ no code projects so far and it really required some customization, some coding and technical understanding from "no code developers".

No code operates together WITH normal developers. At WeLoveNoCode (https://welovenocode.com/) we have mix of no coders who knows design, no code tools but also can dive into code. So it's not like isolated function, no code is an instrument to build something faster with visual editors. Agree?

Also, why see no code as a "competitor" or something completely different? Wix or WordPress was around for a while and only until recently "every" tools decided to call themselves as "no code" :) I mean, it was there for a long time already...

"Also, why see no code as a "competitor" or something completely different?"

Only, solely, and singularly because overexcited no-code proponents are holding it up as such. Otherwise it's no problem.

I actually came up with the insight I posted above while I was typing it. There'll probably some future variant of this post that has it expressed more cleanly, instead of burying what should have been the lede.

I'd say that no-code advocates should be more careful about their messaging; I understand the desire to sell to management, but pissing off "normal" developers is eating your seed corn. There's also architectural ways that manifests in the product itself, where if you think "normal" code is an exception, you'll build it as an exception, and cut yourself off from later growth.

If everyone understood no-code as a follower (and honestly, generally a rather late one... the developer community as a whole needs to process things down to maximum degree before it's ready for the non-developer community), and everyone involved saw it that way, I think we'd end up with a productive harmony. If no-code developers insist on attacking developers (or attacking their job security, or attacking their credibility with their managers, or attacking their work ethic... no-code advertising has done a lot of these sorts of things), it's going to raise hostility and ultimately be self-defeating for the no-code startups.

Did you have any cases when devs collaborate with no-code devs?