I recognize COBOL may not seem like "no-code", but that's just because "no-code" is a stupid label. "No-code" doesn't mean "no code" just like "serverless" still runs on a server.
I would say the main problem with the no-code hype is the idea that it is a leader. It is not. It is a follower. "Normal" code goes out, hammers things out over the course of literally decades, and then, when it has finally settled what the best couple of ways to do something is, it's finally time for the "no code" solutions to come in and systematize that for a larger audience. Nothing wrong with that. Power to the people and all that.
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. That's not the direction the stream flows in. No-code can't operate without the "normal" developers doing immense amounts of work charting the territory and building the infrastructure to get there. There is no chance of them displacing "normal" software developers; they are structurally incapable of it. Woe unto the no-code startup that doesn't understanding this dynamic, and foolishly tries.
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
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.
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.
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.
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.
Yes, usually an order of magnitude more complex, even.
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.
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.
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.
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.
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.
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.
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.
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.”
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)
"no code" like most IT industry buzzwords over the last 70 years, is mostly bullshit but with a kernel of useful truth.
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?)
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.
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 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.
The idea was to convert women who had been working _as_ computers, into programmers.
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.
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...
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.
