Ask HN: What do you think about the no-code movement?
403 comments
It's interesting, but always calibrate their claims against the fact this is about the tenth time this movement has come around. This movement literally goes back to COBOL. That is not a typo. It's not only likely older than you are, but probably much older than you are.
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.
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 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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
[deleted]
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.
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?
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.
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.
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.
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.
OK, but web development is an area that jerf would probably classify as "solved".
> 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.
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.
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.
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.
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.
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.
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.”
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)
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.
"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?)
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.
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)
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.
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".
"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.
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.
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.
The idea was to convert women who had been working _as_ computers, into programmers.
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...
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.
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?
This is an imperfect analogy, but consider for a moment the role Microsoft Excel plays.
Excel allows non-coders to do many useful things, and provides a relatively gentle on-ramp to actual code via formulas. If you take that on-ramp and keep going, towards VBA and add-ins and other pieces of Microsoft technology, you might wind up becoming a full-time software developer, leaving Excel behind and using “real” tools.
Now, there’s a happy path and an unhappy path here.
The happy path is that you use Excel for what it’s good at, but recognize when you are operating at its limits, and at that point pivot into “real” software engineering tools.
The unhappy path is that you stick with Excel too long and become mired in the world of VBA and advanced formulas and attempts at shared workbooks, and build pseudo-database application-contraptions.
No-code can be like that early Excel usage: it can grant some limited but useful powers to non-developers. But no-code can also evolve to become like those contorted, unmaintainable spreadsheet monstrosities that stretch the technology far beyond the point where some “real” software engineering would have been the right answer.
Short version: use the right tool for the job.
Excel allows non-coders to do many useful things, and provides a relatively gentle on-ramp to actual code via formulas. If you take that on-ramp and keep going, towards VBA and add-ins and other pieces of Microsoft technology, you might wind up becoming a full-time software developer, leaving Excel behind and using “real” tools.
Now, there’s a happy path and an unhappy path here.
The happy path is that you use Excel for what it’s good at, but recognize when you are operating at its limits, and at that point pivot into “real” software engineering tools.
The unhappy path is that you stick with Excel too long and become mired in the world of VBA and advanced formulas and attempts at shared workbooks, and build pseudo-database application-contraptions.
No-code can be like that early Excel usage: it can grant some limited but useful powers to non-developers. But no-code can also evolve to become like those contorted, unmaintainable spreadsheet monstrosities that stretch the technology far beyond the point where some “real” software engineering would have been the right answer.
Short version: use the right tool for the job.
> Excel allows non-coders to do many useful things
I heard a great quip at some point: "Why is Excel the most useful IDE?" Answer: "Because it's the one IDE every business allows every user to access."
Most of us here have forgotten that many businesses flat out ban access to programming tools for the majority of users.
And what is an enterprising user to do, when they realize they're performing the same process 100 times a day?
Reach for the only wrench they've been given access to.
PS: I guess an analogy would be people griping about shell scripting, without considering that someone might not have the ability to install their framework of choice when connecting into a client server. It gets the job done, with the tools available.
I heard a great quip at some point: "Why is Excel the most useful IDE?" Answer: "Because it's the one IDE every business allows every user to access."
Most of us here have forgotten that many businesses flat out ban access to programming tools for the majority of users.
And what is an enterprising user to do, when they realize they're performing the same process 100 times a day?
Reach for the only wrench they've been given access to.
PS: I guess an analogy would be people griping about shell scripting, without considering that someone might not have the ability to install their framework of choice when connecting into a client server. It gets the job done, with the tools available.
I definitely think that's a large part of it, but I saw impressive uses of Excel and Access by non-coders long before it was typical to lock-down workstations the way corporations do nowadays (like, 20 years ago).
Excel is used because it's understood by business types, not because it's the only thing available. They're comfortable with spreadsheets, it's no surprise that they'll try to solve any given problem they have with spreadsheets.
You see the same thing in reverse, with programmers reaching for Python when Excel probably would've been a better choice. Everyone reaches for what's familiar.
You see the same thing in reverse, with programmers reaching for Python when Excel probably would've been a better choice. Everyone reaches for what's familiar.
I regularly have issues with new hire data scientists straight out of Uni.
Connect to database, pull multiple tables into pandas / numpy. Then start joining to find the records they want in python.
Why, why, why ???
Connect to database, pull multiple tables into pandas / numpy. Then start joining to find the records they want in python.
Why, why, why ???
100 x this. Most companys ban all kind of software. So Excel is the only solution for really all kind of problems.
Some years ago someone posted here on HN an excel extension that turned excel into an actual IDE.
While it’s true for a lot of people is the only choice, there’s also an amazing amount of enterprising users that sadly don’t know any better!
While it’s true for a lot of people is the only choice, there’s also an amazing amount of enterprising users that sadly don’t know any better!
That's the Venn diagram problem: how many people are there who (a) understand the needs of line of business non-developers, (b) understand their corporate IT policies that non-developers suffer under, (c) know the better way that other developers do it, & (d) are willing to wade through the political and policy @&$& to actually get something done about it?
In my experience, not too many. Non-developers don't know what they don't know, and developers don't know what non-developers need.
In my experience, not too many. Non-developers don't know what they don't know, and developers don't know what non-developers need.
> Most of us here have forgotten that many businesses flat out ban access to programming tools for the majority of users.
That sounds... counter productive to say the least.
That sounds... counter productive to say the least.
You get no argument from me, but I've seen it too frequently to believe it's not by design.
Typically the rationale given is "Non-developers can't be trusted to write code and follow development policies," while leaving the unspoken that they're limiting development to people who by their organizational seat definition aren't experts in the problem they're being asked to code.
Typically the rationale given is "Non-developers can't be trusted to write code and follow development policies," while leaving the unspoken that they're limiting development to people who by their organizational seat definition aren't experts in the problem they're being asked to code.
Very true and a good post. Many managers and companies will go bananas if an employee wants to "program" any custom solutions for repetitive processes or for perceived efficiency. Then on the flip side, if the same employee gets "creative" with Excel, they are all for it, and smiling.
Problem is, Excel can be like trying to fit a square peg in a round hole, might be the wrong tool, or the less efficient option.
Nothing like watching various companies do absolute insanity and cause severe eye pain with convoluted and mangled up Excel spreadsheets. "Damn, at least go use MS Access or MS Project, if you going down this path."
Problem is, Excel can be like trying to fit a square peg in a round hole, might be the wrong tool, or the less efficient option.
Nothing like watching various companies do absolute insanity and cause severe eye pain with convoluted and mangled up Excel spreadsheets. "Damn, at least go use MS Access or MS Project, if you going down this path."
It’s also useful to know some VBScript. I’m not allowed to install Python or any other “actual” programming tool on my Citrix VDI but VBScript runs fine and is pretty capable.
Excel is a great example of how “low code” or “no code” are recent buzzwords for a long continuing evolution. There have long been attempts to make software development more accessible. Some attempts stuck (Crystal Reports 1984, Excel 1987, WordPress 2003, IFTTT 2010) while others did not (HyperCard 1987, FrontPage 1995). The same will be true for the current crop of platforms.
Seems like you either die a hero or you live long enough to see yourself become a villain.
I don't agree: Frontpage was definitely a villain.
Not as villain as Dreamweaver. Not directly but considering how MS saw that has no future and abandoned it, while Dreamweaver became the "web dev tool" for many, many out there for long years until Adobe understood those tools had no future at all.
Pfft. Dreamweaver (and even FrontPage) were perfectly fine back in the pre-IE6 days when they dominated.
People today crap on using <TABLE>'s for grid formatting, just as we crap on 1990's Java code for its `AbstractStrategyFactoryFactory` excesses. Because it's "what people did back in the bad old days", and is a glaring red flag that one's skills are out of date.
But whereas OO design patterns are a matter of subjective debate, early HTML4 and prior just flat out didn't have modern mechanism for separating presentation and content. CSS 1.x was very limited, and no major web browser even seriously supported that until the year 2000. CSS 2.x didn't get real until the 2010's.
Would any professional use Dreamweaver today? Of course not. But it was an appropriate tool for its time.
People today crap on using <TABLE>'s for grid formatting, just as we crap on 1990's Java code for its `AbstractStrategyFactoryFactory` excesses. Because it's "what people did back in the bad old days", and is a glaring red flag that one's skills are out of date.
But whereas OO design patterns are a matter of subjective debate, early HTML4 and prior just flat out didn't have modern mechanism for separating presentation and content. CSS 1.x was very limited, and no major web browser even seriously supported that until the year 2000. CSS 2.x didn't get real until the 2010's.
Would any professional use Dreamweaver today? Of course not. But it was an appropriate tool for its time.
FrontPage from day one generated garbage that only IE could read, on purpose. The other day I found a notebook from my high school days in which I attached a "Best viewed in your own browser" sticker to mock the best viewed on IE (and also Netscape) buttons that were the rage back in the day (pre-2000).
Pre-IE6 days, sure. I'm talking about much later, Adobe abandoned DW just a few years ago, much, much later than it should have been.
I would go further and say Excel is the ultimate no-code solution. It has been used by more people to solve coding like problems by non-coders than any other no-coding tool.
I kind of disagree, because what I often see is people causing more difficulties for themselves than if they made the jump to Access, SQL, or even building an application.
There is arguably a kind of limit to how far one should take using Excel. Microsoft clearly knows this, so has Access waiting there for those that figure out they should go the next level up. Even then, Access might not be the best answer, as compared to creating an application that addresses specific needs.
There is arguably a kind of limit to how far one should take using Excel. Microsoft clearly knows this, so has Access waiting there for those that figure out they should go the next level up. Even then, Access might not be the best answer, as compared to creating an application that addresses specific needs.
I disagree that these are coding problems. Just math isn't coding. These might be real problems that are difficult to solve, and that problem solving happens on a computer, but that doesn't make it coding.
I mostly agree. But I think there’s an important semantic distinction: people who use excel are coders. They are programming the moment they write an expression into a cell.
I think this is important because we fool ourselves by calling these people non-coders.
Excel is really just a coding environment that has a ridiculously smooth learning curve.
I think this is important because we fool ourselves by calling these people non-coders.
Excel is really just a coding environment that has a ridiculously smooth learning curve.
Yeah, this is why the term "low code" seems more appriorpiate. We should definitely be describing `=A1+B1` as "code" and we should be calling it the "Excel Programming Langauge". (Especially now with LET and LAMBDA and compound data types making it Turing complete).
(However it's still low code because all the imperative stuff about the GUI and loading/saving files and updating other cells reactively and so-on is written for you by Microsoft.)
(However it's still low code because all the imperative stuff about the GUI and loading/saving files and updating other cells reactively and so-on is written for you by Microsoft.)
It's a perfect analogy. Don't sell yourself short. Look, the following things are true.
1) This industry absolutely has the capability create more tools like Excel that are both extremely empowering and orders of magnitude easier than what we think of as coding.
2) Unfortunately, there's a strong, likely frequently subconscious, incentive to definitely not do this, since it carries a strong danger of IT making itself "obsolete."
(Not judging here, just observing)
1) This industry absolutely has the capability create more tools like Excel that are both extremely empowering and orders of magnitude easier than what we think of as coding.
2) Unfortunately, there's a strong, likely frequently subconscious, incentive to definitely not do this, since it carries a strong danger of IT making itself "obsolete."
(Not judging here, just observing)
> 2) Unfortunately, there's a strong, likely frequently subconscious, incentive to definitely not do this, since it carries a strong danger of IT making itself "obsolete."
I can't think of a single case that this has ever been the decision making process when creating a product.
If you look at the myriad of available tools that trends in this direction, in all fields, you'll realize that the industry is littered with both successful and failed examples, ERP systems alone are a huge market.
It's just that people wanted to replace actual convoluted general purpose logic known as coding, that they ran into problem that could not be addressed by some GUI. And that no-code solutions that exist today propagandize about.
I can't think of a single case that this has ever been the decision making process when creating a product.
If you look at the myriad of available tools that trends in this direction, in all fields, you'll realize that the industry is littered with both successful and failed examples, ERP systems alone are a huge market.
It's just that people wanted to replace actual convoluted general purpose logic known as coding, that they ran into problem that could not be addressed by some GUI. And that no-code solutions that exist today propagandize about.
What? I can think of a ton egregious examples of deliberate "disempowering" right off the top, to say nothing of the likely TONS more subtle ones.
Shutting down Hypercard.
Google Reader.
Bill Gates emphasizing to NOT make MS docs compatible with others. The list goes on and on.
Shutting down Hypercard.
Google Reader.
Bill Gates emphasizing to NOT make MS docs compatible with others. The list goes on and on.
How are any of these related to making IT obsolete?
I would think the incentive to make a bazillion dollars if you did this sucessfully would outweigh your purported frequently subconscious disincentive.
Plus there are other people in this comments thread saying they are working for companies that are (they claim) doing so. Not to mention all the past attempts to do so over the past 40 years. Is the idea that those companies are intentionally not doing it as well as they could, because of their allegience to not making the field of IT obsolete?
The idea that we collectively could easily be making software construction toolkits for non-programmers that would make "IT obsolete", it's an easy problem, but we just choose not to... is a conspiracy theory.
Plus there are other people in this comments thread saying they are working for companies that are (they claim) doing so. Not to mention all the past attempts to do so over the past 40 years. Is the idea that those companies are intentionally not doing it as well as they could, because of their allegience to not making the field of IT obsolete?
The idea that we collectively could easily be making software construction toolkits for non-programmers that would make "IT obsolete", it's an easy problem, but we just choose not to... is a conspiracy theory.
I'd argue there's a massive incentive to do this if you can because then every other company in the world can downsize their engineering staff and take advantage of the no code solution that you're selling. Even if you sell at an absurd price like $1M/year but it allows a company to replace 10 programmer, it'd probably be worth it.
The problem is as it's always been. Solving problems in the general sense is hard. It is true in design, it is true in AI, it is true in the automotive world, and on the battlefield. Specialized for one task is easier to learn, and easier to design for. General is harder to learn, and harder to design for.
With that in mind, it's interesting that we still even have "general-purpose programming languages." There is some specialization for sure, but that's partly because of things like e.g. the browser only supports Javascript. And then you see things going back the other way, e.g. with NodeJS.
So I'd wait till we see some actual, real specialization in the languages / tools that engineers use, beyond "ecosystem" reasons. In the meantime, we've seen tools that help non-programmers "automate" things. Everything from CAD to Wix, Salesforce, Figma, etc. would fall under that umbrella. But then you still have code. If what you want is automation / labor-force-multipliers, the common denominator will still be highly generalized, and therefore, hard.
With that in mind, it's interesting that we still even have "general-purpose programming languages." There is some specialization for sure, but that's partly because of things like e.g. the browser only supports Javascript. And then you see things going back the other way, e.g. with NodeJS.
So I'd wait till we see some actual, real specialization in the languages / tools that engineers use, beyond "ecosystem" reasons. In the meantime, we've seen tools that help non-programmers "automate" things. Everything from CAD to Wix, Salesforce, Figma, etc. would fall under that umbrella. But then you still have code. If what you want is automation / labor-force-multipliers, the common denominator will still be highly generalized, and therefore, hard.
I suppose the difficult part is figuring when you've crossed the fine line from "good enough for now" to "this is becoming a monstrosity, we need to hire developers and create our own software now"
The second difficult part is when the team that built the "good enough for now" realizes that the line was crossed, that they do not have the skills to be part of the "hire developers and create our own software now" solution and then start subtly, or even openly, sabotaging every effort to move away from the Excel/VBA solution.
Case-in-point, there are more than a few non-software engineering firms where the entire business is a series of mind-boggling amalgamations of Excel and VBA with a healthy dose of Matlab on the side. I'm talking full applications written in VBA with Excel as the interface. I wouldn't be surprised to see the same in non-quant finance.
>>>> The unhappy path is that you stick with Excel too long and become mired in the world of VBA and advanced formulas and attempts at shared workbooks, and build pseudo-database application-contraptions.
How happy was the "let's just spin up a software project" path?
How happy was the "let's just spin up a software project" path?
There's a second version of the unhappy path, as well: you're trying to use the tool for what it's good for, but there's a bug that makes your particular use case unnecessarily difficult. At worst, what happens is you silently either get bad results or lose data. At best, you either don't use the tool for that purpose until the bug is fixed, or, you implement some silly workaround. All in all, this can be a rather disempowering situation for a non-technical user, which is the exact opposite of what "no code" promises.
TL;DR: "no code" is just somebody else's code. You're introducing a massive external dependency you have little control over by using a "no code" solution.
TL;DR: "no code" is just somebody else's code. You're introducing a massive external dependency you have little control over by using a "no code" solution.
I am an engineer with 20+ years of hands on keyboard, I've got projects that are now part of Apache, 1000's of stars on github. I've been CTO at a number of startups that have got significant funding. My point is to establish some credibility. I probably still suck.
Having said that, I have been working with Microsoft PowerAutomate for the past 1.5 years and while it has saved a lot of time and been overall a good experience, there are times when the no code/low code gets in the way and I wish I could just "drop into code" to get something done. Examples are things like data validation. This technology is not going to replace coding, the paradigm shift is really happening for people in the marketing and sales operations parts of the business. For these folks, this tech is life changing. In a lot of ways, this tech felt like when you try a new framework in your language of choice; at first it's super easy and you get hyped, and then you hit a requirement where the nocode/lowcode environment really gets in the way.
Having said that, I have been working with Microsoft PowerAutomate for the past 1.5 years and while it has saved a lot of time and been overall a good experience, there are times when the no code/low code gets in the way and I wish I could just "drop into code" to get something done. Examples are things like data validation. This technology is not going to replace coding, the paradigm shift is really happening for people in the marketing and sales operations parts of the business. For these folks, this tech is life changing. In a lot of ways, this tech felt like when you try a new framework in your language of choice; at first it's super easy and you get hyped, and then you hit a requirement where the nocode/lowcode environment really gets in the way.
I think this is spot-on. No-code solutions allow non-technical folks in marketing and sales to build some amazing things that would have required teams of software engineers: marketing, shopping cart, and email integrations; email onboarding workflows; complex ad campaigns; better inventory and wholesale sales management; and a lot of other things I'm not creative enough to think of. I've seen an entire application prototype built by a product manager by duct taping Google Sheets, Mailchimp, and a database together with Zapier.
However, their wants always grow just beyond the no-code capabilities, and there's still a need for software engineers for things that haven't been fully solved yet.
However, their wants always grow just beyond the no-code capabilities, and there's still a need for software engineers for things that haven't been fully solved yet.
IMHO, the best fusion of the two is offering a no-code tool to non-technical folks... while ensuring you have a tiger team of random and varied developers to produce one-off duct tape bits to cover gaps for them.
It seems far more efficient to have a non-technical person fiddle with a GUI, get most of the way on data integration, etc., and then come to the team with only the parts they couldn't figure out.
"I have this list of strings and I need to X" or "I need to push data to this API"
We did something similar at a previous job, and it generally worked out well. The code assistance kept people from constructing Rube Goldberg machines in the designer tool, to solve simple coding problems that the tool couldn't cover.
It seems far more efficient to have a non-technical person fiddle with a GUI, get most of the way on data integration, etc., and then come to the team with only the parts they couldn't figure out.
"I have this list of strings and I need to X" or "I need to push data to this API"
We did something similar at a previous job, and it generally worked out well. The code assistance kept people from constructing Rube Goldberg machines in the designer tool, to solve simple coding problems that the tool couldn't cover.
> I wish I could just "drop into code" to get something done.
Since you're using PowerPlatform you can prob easily do that with Microsoft's Power FX, built - I believe - especially for this.
https://docs.microsoft.com/en-us/power-platform/power-fx/ove...
Since you're using PowerPlatform you can prob easily do that with Microsoft's Power FX, built - I believe - especially for this.
https://docs.microsoft.com/en-us/power-platform/power-fx/ove...
I'm confused about the intended audience.
Power FX has a level of abstraction squeezed between MS's other options (excel formulae,power query M/DAX, Powershell, C#).
It gives the impression of a pet project rather than something users actually asked for.
Power FX has a level of abstraction squeezed between MS's other options (excel formulae,power query M/DAX, Powershell, C#).
It gives the impression of a pet project rather than something users actually asked for.
thank you for pointing this out! Microsoft is so vast in its offerings, sometimes you can't even find the thing you believe must exist.
I’ve had a different experience with PowerAutomate.
Both as a no-coder and a user.
As a user the UX is horrible and I’m now swamped with terrible “apps” or “workflows” that people try to get me to use and fail for arcane reasons. Or are just ugly or brittle.
As a no-coder the tools are hit or miss, the docs are bad, and widgets frequently don’t work due to my licensing and there’s no way to know other than to try and see.
It has such promise as the shell scripting equivalent for the cloud what shell was to PCs. But instead it is a costly and difficult thing to use.
Both as a no-coder and a user.
As a user the UX is horrible and I’m now swamped with terrible “apps” or “workflows” that people try to get me to use and fail for arcane reasons. Or are just ugly or brittle.
As a no-coder the tools are hit or miss, the docs are bad, and widgets frequently don’t work due to my licensing and there’s no way to know other than to try and see.
It has such promise as the shell scripting equivalent for the cloud what shell was to PCs. But instead it is a costly and difficult thing to use.
I find the UX horrible for different reasons, ones that I believe are pretty easy for microsoft to address if they just watched someone like me use the product.
I have not experienced the brittleness, maybe what I am doing is more trivial.
It has such promise as the shell scripting equivalent for the cloud what shell was to PCs.
What ever happened to Yahoo Pipes?
What ever happened to Yahoo Pipes?
I really miss yahoo pipes.
I played with Huginn a bit, but it’s a steeper learning curve.
I feel like the promise of the Internet has really been blocked off my adding in some nice business models. So now companies don’t want interoperability and orchestration as that stuff just reduces revenue. Why would goog/face/etc want us spending less time doing mundane tasks. They want us spending the max amount of manual stuff as long as we don’t quit.
I played with Huginn a bit, but it’s a steeper learning curve.
I feel like the promise of the Internet has really been blocked off my adding in some nice business models. So now companies don’t want interoperability and orchestration as that stuff just reduces revenue. Why would goog/face/etc want us spending less time doing mundane tasks. They want us spending the max amount of manual stuff as long as we don’t quit.
> I am an engineer with 20+ years of hands on keyboard, I've got projects that are now part of Apache, 1000's of stars on github. I've been CTO at a number of startups that have got significant funding. My point is to establish some credibility. I probably still suck.
More about being in a right place at a right time, but granted.
> Having said that, I have been working with Microsoft PowerAutomate for the past 1.5 years and while it has saved a lot of time and been overall a good experience, there are times when the no code/low code gets in the way and I wish I could just "drop into code" to get something done. Examples are things like data validation. This technology is not going to replace coding, the paradigm shift is really happening for people in the marketing and sales operations parts of the business. For these folks, this tech is life changing. In a lot of ways, this tech felt like when you try a new framework in your language of choice; at first it's super easy and you get hyped, and then you hit a requirement where the nocode/lowcode environment really gets in the way.
I think higher-level languages with a dual code-graphic representation and a possibility to drop into lower level are an interesting option, but even that is not new - Unreal/Unity3D etc.
More about being in a right place at a right time, but granted.
> Having said that, I have been working with Microsoft PowerAutomate for the past 1.5 years and while it has saved a lot of time and been overall a good experience, there are times when the no code/low code gets in the way and I wish I could just "drop into code" to get something done. Examples are things like data validation. This technology is not going to replace coding, the paradigm shift is really happening for people in the marketing and sales operations parts of the business. For these folks, this tech is life changing. In a lot of ways, this tech felt like when you try a new framework in your language of choice; at first it's super easy and you get hyped, and then you hit a requirement where the nocode/lowcode environment really gets in the way.
I think higher-level languages with a dual code-graphic representation and a possibility to drop into lower level are an interesting option, but even that is not new - Unreal/Unity3D etc.
Why are you trying to diminish his accomplishments? Does that make you feel better, to try to bring someone down? You come off as bitter and unaccomplished and this site could use less of people like you.
Maybe ask some of these people:
1 hour before you Ask HN: Do you like the term 'nocode'? https://news.ycombinator.com/item?id=29187754
2 days ago Ask HN: No Code GUI Tools? https://news.ycombinator.com/item?id=29160858
3 months ago Ask HN: Is there any future for low-code/no-code development? https://news.ycombinator.com/item?id=28150056
4 months ago Ask HN: Anyone built a business with no-code tools? https://news.ycombinator.com/item?id=27593073
3 months ago Ask HN: What do you think of Producthunt's obsession with no-code solutions? https://news.ycombinator.com/item?id=28194430
1 hour before you Ask HN: Do you like the term 'nocode'? https://news.ycombinator.com/item?id=29187754
2 days ago Ask HN: No Code GUI Tools? https://news.ycombinator.com/item?id=29160858
3 months ago Ask HN: Is there any future for low-code/no-code development? https://news.ycombinator.com/item?id=28150056
4 months ago Ask HN: Anyone built a business with no-code tools? https://news.ycombinator.com/item?id=27593073
3 months ago Ask HN: What do you think of Producthunt's obsession with no-code solutions? https://news.ycombinator.com/item?id=28194430
We have to start doing like those Soccer Mom Facebook groups and put something like: "please use the magnifier glass[0] to search if your question hasn't been asked before"
[0] https://hn.algolia.com/
Edit: I'm getting heavily downvoted. Sorry guys, it was just a joke.
[0] https://hn.algolia.com/
Edit: I'm getting heavily downvoted. Sorry guys, it was just a joke.
Not everyone checks HN and Reddit every day.
Just because it's been asked before doesn't mean that the people answering it are the same etc etc
Just because it's been asked before doesn't mean that the people answering it are the same etc etc
Thanks for posting these. I did see these threads before posting this Ask HN. However in most of those threads there wasn't much discussion at all.
I'm finding the comments in the current thread quite enriching to be honest.
I'm finding the comments in the current thread quite enriching to be honest.
Most of these posts have less than ten comments where this one is at 317 currently. It's no secret you gotta "win the HN lottery" before traction on a post occurs, repeated submissions are going to be a natural consequence of that.
Ouch! Ok, somebody came ready to rock-n-roll on questions. Originally I read, for example, "4 months ago" instead as "4 months before asking HN [see link here]" as in don't ask answered questions!
The ultimate "low code" experience I had was back in the 1990s with Delphi. You drag and drop your form elements, get everything just right. Next you hook up your event handlers and type in a few lines of code to do the actual work.
It was the best I've ever seen balance of managing complexity, yet letting you write code when you needed to.
The C++ version was nowhere near as god, it generated a ton of templates and things that just weren't necessary in Pascal.
Since then everything is expected to work across the internet, through a web browser, web server, etc. It'll never be as simple and effective as it was.
It was the best I've ever seen balance of managing complexity, yet letting you write code when you needed to.
The C++ version was nowhere near as god, it generated a ton of templates and things that just weren't necessary in Pascal.
Since then everything is expected to work across the internet, through a web browser, web server, etc. It'll never be as simple and effective as it was.
>The ultimate "low code" experience I had was back in the 1990s with Delphi. You drag and drop your form elements, get everything just right. Next you hook up your event handlers and type in a few lines of code to do the actual work.
Today I was thinking about Visual Basic 6, which worked more or less the same way.
I wonder what similar alternatives we have today? Gambas? https://en.wikipedia.org/wiki/Gambas
Today I was thinking about Visual Basic 6, which worked more or less the same way.
I wonder what similar alternatives we have today? Gambas? https://en.wikipedia.org/wiki/Gambas
The problem is that you can’t usually afford to target just a Windows 95 PC or equivalent today so such a tool cannot exist. The UI must morph and adapt and feel native across phones, tablets, retina displays, etc.
Even video games these days need to adapt to a different UX on each platform even thou they are the closest to having one unified UI across the gamut
Even video games these days need to adapt to a different UX on each platform even thou they are the closest to having one unified UI across the gamut
It's unrealistic to expect a full, productive, desktop experience on any smaller devices.
Giving up on the desktop is a huge step backwards.
Giving up on the desktop is a huge step backwards.
On the other hand, the market has expanded beyond economies where users have the space, power and physical safety to actually own a desktop. For some people their first, last and only "PC" is their smartphone. Your choice then becomes embracing those users or not having those users at all.
I like typing stuff in and instantly seeing the results, rather than rat wrestling widgets onto a form. Rat wrestling also makes adaptive UIs difficult; again, the solution is being able to declare your UI with layout managers that apply constraints.
The most rapid UI tool I've ever encountered is Tcl/Tk. Everything else involves incurring more tedium and misery -- even Visual Basic or Delphi.
The most rapid UI tool I've ever encountered is Tcl/Tk. Everything else involves incurring more tedium and misery -- even Visual Basic or Delphi.
Delphi is alive! https://www.embarcadero.com/products/delphi
> The UI must morph and adapt and feel native across phones, tablets, retina displays, etc.
Isn't that a solved problem by the likes of React Native?
Isn't that a solved problem by the likes of React Native?
https://www.lazarus-ide.org/
Quoting:
Highlights
- Open Source
- Written in Pascal for Pascal
- Cross-platform
- Over 200 Components
- Extendable through packages
- Package Manager with Online Repositry
- Many Frameworks
- Converts from Delphi code
- Regular Releases
Quoting:
Highlights
- Open Source
- Written in Pascal for Pascal
- Cross-platform
- Over 200 Components
- Extendable through packages
- Package Manager with Online Repositry
- Many Frameworks
- Converts from Delphi code
- Regular Releases
You can do "drag and drop form elements and type up the event handlers" with Visual Studio and C#. The problem is that Microsoft have rather lost their way on GUI frameworks - too many of them and the latest ones are either "to be obsolete" or "not finished yet" (winui3), and winui3 has broken the interactive designer.
Theoretically it can be multi-platform https://platform.uno/
Theoretically it can be multi-platform https://platform.uno/
WinForms is the spiritual successor to VB6.
I'm not sure where the "confusion" about your options is coming from because Delphi (Object Pascal) still exists. You can get the Free Community Edition from here- https://www.embarcadero.com/products/delphi/starter/free-dow...
If a person knows Delphi/Pascal, there is no need for them to use Visual Basic 6, unless that was their feeling about such. There are several Object Pascal options to choose from, where if a person was previously exposed to Pascal/Turbo Pascal/Delphi, they would be able to get back up to speed very quickly.
As you mentioned Gambas, maybe you are thinking completely free and open-source, which Object Pascal has such too. The most obvious choice would be Free Pascal with the Lazarus IDE. For those that don't know or are confused, Delphi is a dialect of the Object Pascal programming language (check Wikipedia or Embarcadero website to verify). So the closest dialect of Object Pascal to what is used in Delphi (the IDE), would be Free Pascal/Lazarus. You can even import and convert Delphi projects (including Turbo Pascal) to Free Pascal/Lazarus. You can get Free Pascal/Lazarus from below:
https://www.lazarus-ide.org/index.php?page=downloads
https://github.com/LongDirtyAnimAlf/fpcupdeluxe (this is a special cross-platform installer)
There are also other dialects of Object Pascal that are free and open-source, such as PascalABC, which is a variation for .NET. You can check it out here- https://github.com/pascalabcnet/pascalabcnet
If a person knows Delphi/Pascal, there is no need for them to use Visual Basic 6, unless that was their feeling about such. There are several Object Pascal options to choose from, where if a person was previously exposed to Pascal/Turbo Pascal/Delphi, they would be able to get back up to speed very quickly.
As you mentioned Gambas, maybe you are thinking completely free and open-source, which Object Pascal has such too. The most obvious choice would be Free Pascal with the Lazarus IDE. For those that don't know or are confused, Delphi is a dialect of the Object Pascal programming language (check Wikipedia or Embarcadero website to verify). So the closest dialect of Object Pascal to what is used in Delphi (the IDE), would be Free Pascal/Lazarus. You can even import and convert Delphi projects (including Turbo Pascal) to Free Pascal/Lazarus. You can get Free Pascal/Lazarus from below:
https://www.lazarus-ide.org/index.php?page=downloads
https://github.com/LongDirtyAnimAlf/fpcupdeluxe (this is a special cross-platform installer)
There are also other dialects of Object Pascal that are free and open-source, such as PascalABC, which is a variation for .NET. You can check it out here- https://github.com/pascalabcnet/pascalabcnet
> Today I was thinking about Visual Basic 6, which worked more or less the same way.
VB .NET, which is just Visual Basic now, is like that and is "modern".
VB .NET, which is just Visual Basic now, is like that and is "modern".
The first one I encountered from that same era was Interface Builder, on the NeXT. And it turns out it's still around, as part of XCode on the Mac.
It's been 10 years now, but the Visual Studio GUI/Winforms designer was (probably still is) similar - and being .NET, you could get some pretty decent software up and running without too much code - depending on which language you used.
I used Delphi a lot in the 90's and early 00's, but I never really considered it "low code", with the exception of the drag and drop forms designer of course.
A lot of companies, especially from Russia and Ukraine, sold visible and invisible VCL components that you could drop on the form and configure. Depending on your functionality you needed very little or no code at all. We a lot of applications that way in the 90s and begin 00s.
It depends very much on what functionality you needed.
If you needed a GUI for database CRUD operations (which is a lot of business processes and a lot of webapps now), then you could do that with nearly zero code, as the built-in behavior was all that you needed, but if you needed some interesting custom script and just a button "run it" and a textbox for results, then of course that would be nearly all your own code.
If you needed a GUI for database CRUD operations (which is a lot of business processes and a lot of webapps now), then you could do that with nearly zero code, as the built-in behavior was all that you needed, but if you needed some interesting custom script and just a button "run it" and a textbox for results, then of course that would be nearly all your own code.
I remember Borland C++ builder being similar. Was actually pretty good to use.
The “no code” and “low code” movements come up over and over again because programming is now like writing: Yes, it is its own profession, but also yes, it permeates all other professions as software eats the world.
Languages and tools are user interfaces, and any time you have many different jobs to be done by many different people with many different contexts, it is natural to develop several different interfaces for what may appear to be the same work.
Thus, low-code and no-code. But!
Programming is more than just coding. It’s also all the activities AROUND the coding, including things like reviewing code before it is deployed, version control, reverting code, testing code, automated tests that also serve as DSLs for describing the behaviour of code, &c.
Robust no-code or low-code systems also need to address the needs that the systems and tooling that live around high-code serve.
They don’t need to do these things the exact same way, but it’s a Chesterton’s Fence situation: We shouldn’t just ignore those other systems, we should figure out why they exist and make sure that either we know those needs no longer exist, or address them another way.
https://raganwald.com/2012/01/08/duck-programming.html
Discussion around the original post:
https://news.ycombinator.com/item?id=3442419
Languages and tools are user interfaces, and any time you have many different jobs to be done by many different people with many different contexts, it is natural to develop several different interfaces for what may appear to be the same work.
Thus, low-code and no-code. But!
Programming is more than just coding. It’s also all the activities AROUND the coding, including things like reviewing code before it is deployed, version control, reverting code, testing code, automated tests that also serve as DSLs for describing the behaviour of code, &c.
Robust no-code or low-code systems also need to address the needs that the systems and tooling that live around high-code serve.
They don’t need to do these things the exact same way, but it’s a Chesterton’s Fence situation: We shouldn’t just ignore those other systems, we should figure out why they exist and make sure that either we know those needs no longer exist, or address them another way.
https://raganwald.com/2012/01/08/duck-programming.html
Discussion around the original post:
https://news.ycombinator.com/item?id=3442419
It's weird from the perspective of game development because it's so obvious. A lot of time is spent on development tools because making a modern game is a very complex undertaking that is highly data-driven. A large amount of game tools are #nocode not because it's a movement but because it's useful. A classic example is level design tools that are much more about spatial design with some coupling between entities in a game. Non-programmers can get really far and build some surprising diverse things with simple primitives.
As an example our Art Director built this without any programmer assistance or writing a line of code. Just taking a basic multiplayer FPS game then grabbing components we had already made and jamming them together to get parts working: https://twitter.com/voxeleus/status/1437754413813207047/vide...
You can further see this in many creative games or games with modding tools where players put together complex behavior without using a line of code. Right up to things like Minecraft Redstone which is really an esoteric, spatial programming language. But crucially doesn't feel much like programming at all.
I think there's a lot to be taken from the game space for people trying to build no-code tools. Particularly in that you're not trying to remove a programmer but empower non-programmers in ways that suit them.
As an example our Art Director built this without any programmer assistance or writing a line of code. Just taking a basic multiplayer FPS game then grabbing components we had already made and jamming them together to get parts working: https://twitter.com/voxeleus/status/1437754413813207047/vide...
You can further see this in many creative games or games with modding tools where players put together complex behavior without using a line of code. Right up to things like Minecraft Redstone which is really an esoteric, spatial programming language. But crucially doesn't feel much like programming at all.
I think there's a lot to be taken from the game space for people trying to build no-code tools. Particularly in that you're not trying to remove a programmer but empower non-programmers in ways that suit them.
I feel like there is a distinction between tools and no code and these are just tools. You can maybe prototype a game mechanic if it’s not very unique with drag and drop but it’ll never scale to production. By the end the game code will have thousands of special cases which would make the nice no code experience a complete Frankenstein monster
> I feel like there is a distinction between tools and no code and these are just tools.
How would you describe the difference?
How would you describe the difference?
> I feel like there is a distinction between tools and no code and these are just tools.
Programming is just a tool as well... there's a odd distinction here that somehow more specific tools are lesser. I also think this is where the whole #nocode thing can go wrong. You should empower non-programmers in ways that suit them.
> You can maybe prototype a game mechanic if it’s not very unique with drag and drop but it’ll never scale to production.
The expressiveness of composition is only limited by the number of elements you have to compose. In the specific zombie case no it wouldn't scale to production. But then the prototype wasn’t meant to and also would never have existed if it weren't for these tools. We unlocked the ability for our Art Director to prototype a new game all by themselves. That's massive from a creativity point of view. We'll almost certainly turn it into a full game at some point.
From a production standpoint a game is thousands of special data cases. Which is why tools are so important and code is both data and a tool but if you can simplify things so much the better.
Programming is just a tool as well... there's a odd distinction here that somehow more specific tools are lesser. I also think this is where the whole #nocode thing can go wrong. You should empower non-programmers in ways that suit them.
> You can maybe prototype a game mechanic if it’s not very unique with drag and drop but it’ll never scale to production.
The expressiveness of composition is only limited by the number of elements you have to compose. In the specific zombie case no it wouldn't scale to production. But then the prototype wasn’t meant to and also would never have existed if it weren't for these tools. We unlocked the ability for our Art Director to prototype a new game all by themselves. That's massive from a creativity point of view. We'll almost certainly turn it into a full game at some point.
From a production standpoint a game is thousands of special data cases. Which is why tools are so important and code is both data and a tool but if you can simplify things so much the better.
I work at Stacker (YC S20) [0] -- we're actively building a part of this future and so I've done a lot of thinking about it.
My view is that, indeed, the general no-code category represents a paradigm shift in the truest sense. That is, it is not going to replace anything we currently use software engineering for, except at the very edges. This is pretty obvious to anyone who understands software and the complexity inherent in building custom things. Rather, it will enable a massive new category of software to be built, where presently it is uneconomical to do so.
Think simple tools, sometimes throwaway tools only needed for a few weeks, tools specific to each new project - things currently implemented with whiteboards and sticky notes that would clearly be better as digital tools in all sorts of ways - and indeed increasingly essential as the assumption that everyone is in the same office gets less true.
This stuff is typically quite straightforward but requires deep domain context that'd be really difficult to translate into a spec, and way too expensive anyway to justify hiring engineers to build, but it can now just be done directly by the domain experts themselves who need not necessarily be technical.
This category is simply massive - think of the number of such tools that could be useful in even a single given business if they were simple and cheap to create. Now multiply that by every business.
If you're convinced / intrigued by any of what I've said, by the way, we are hiring. So let's chat about it more! Email is in my profile :-)
[0] https://stackerhq.com
My view is that, indeed, the general no-code category represents a paradigm shift in the truest sense. That is, it is not going to replace anything we currently use software engineering for, except at the very edges. This is pretty obvious to anyone who understands software and the complexity inherent in building custom things. Rather, it will enable a massive new category of software to be built, where presently it is uneconomical to do so.
Think simple tools, sometimes throwaway tools only needed for a few weeks, tools specific to each new project - things currently implemented with whiteboards and sticky notes that would clearly be better as digital tools in all sorts of ways - and indeed increasingly essential as the assumption that everyone is in the same office gets less true.
This stuff is typically quite straightforward but requires deep domain context that'd be really difficult to translate into a spec, and way too expensive anyway to justify hiring engineers to build, but it can now just be done directly by the domain experts themselves who need not necessarily be technical.
This category is simply massive - think of the number of such tools that could be useful in even a single given business if they were simple and cheap to create. Now multiply that by every business.
If you're convinced / intrigued by any of what I've said, by the way, we are hiring. So let's chat about it more! Email is in my profile :-)
[0] https://stackerhq.com
Nice. Looks similar to the Restya Core. By any chance, did you get any inspiration from the Restya Core?
Looks like a cool company. I'd apply, but it looks like you're only accepting applications from EU timezones.
I have been a professional programmer for forty years. In the eighties, there was a no-code desktop relational database application called Helix. I continue to think that it belongs on the same shelf as Excel in the UI hall of fame.
Like Excel, people made applications with it. Unlike Excel, it created a server product in the mid-eighties that allowed it to become an IT platform. Small business owners who had hacked up a Helix database to help with invoicing were able to extend the function to the entire organization without ever using a keyboard for anything except typing label names on reports. All drag-and-drop icon stuff.
Fast forward twenty-five years. Today the applications have grown and grown and grown. The owners who created them are old, prosperous and tired of screwing around with it. Also, Helix is no longer well supported. These people are screwed.
I consult for a few companies that use it. These apps are exact replicas of the brain process of the owner that made them without a single structured thought in sight. Even if Helix were a healthy platform, the apps are largely unmaintainable.
They are also so complicated and so deeply integrated into the companies that they represent a horrible threat. They can't easily adapt to the modern world and will cost millions to replace.
Which is to say, these no-code systems encourage amateurs to reach too far. I advise people against them.
Like Excel, people made applications with it. Unlike Excel, it created a server product in the mid-eighties that allowed it to become an IT platform. Small business owners who had hacked up a Helix database to help with invoicing were able to extend the function to the entire organization without ever using a keyboard for anything except typing label names on reports. All drag-and-drop icon stuff.
Fast forward twenty-five years. Today the applications have grown and grown and grown. The owners who created them are old, prosperous and tired of screwing around with it. Also, Helix is no longer well supported. These people are screwed.
I consult for a few companies that use it. These apps are exact replicas of the brain process of the owner that made them without a single structured thought in sight. Even if Helix were a healthy platform, the apps are largely unmaintainable.
They are also so complicated and so deeply integrated into the companies that they represent a horrible threat. They can't easily adapt to the modern world and will cost millions to replace.
Which is to say, these no-code systems encourage amateurs to reach too far. I advise people against them.
I wonder if you could find any 'enterprise' system at a business of any size that's lasted 25 years, if it would have much the same problems. And if you can't find many enterprise systems that lasted 25 years, that says something to, in Helix's favor. (some of the ones you can are... COBOL I guess?)
> These apps are exact replicas of the brain process of the owner that made them without a single structured thought in sight.
To be fair, we've probably all seen applications written by professional software engineers that fit that description..
To be fair, we've probably all seen applications written by professional software engineers that fit that description..
Remember Omnis? That was fun to code in, hard to maintain.
I think it a good answer to the wrong question.
The wrong question is: (most/many) people cannot program because it is difficult to type the right things in, so let us remove typing.
The right question should be: how can we more efficiently develop software?
No-one would ever think to start a no-write movement because people cannot write properly. We instead teach everyone to write starting from the first grade, and we build tools to help them write better (dictionaries, word processors, spell checkers).
For programming, we should also concentrate on building tools (like the awesome IDEs of today) that makes developing software more efficient. Some of the efficiency can be had by no-code (i.e., Delphi-style forms), some can be had by improvements to technology (code completion), some can be had by improved language design. We should also invest more in programming education.
Low/no code DSLs are also good (think of Excel).
But I am skeptical of general purpose no-code: if it's Turing-complete, it's just a programming language in disguise.
The wrong question is: (most/many) people cannot program because it is difficult to type the right things in, so let us remove typing.
The right question should be: how can we more efficiently develop software?
No-one would ever think to start a no-write movement because people cannot write properly. We instead teach everyone to write starting from the first grade, and we build tools to help them write better (dictionaries, word processors, spell checkers).
For programming, we should also concentrate on building tools (like the awesome IDEs of today) that makes developing software more efficient. Some of the efficiency can be had by no-code (i.e., Delphi-style forms), some can be had by improvements to technology (code completion), some can be had by improved language design. We should also invest more in programming education.
Low/no code DSLs are also good (think of Excel).
But I am skeptical of general purpose no-code: if it's Turing-complete, it's just a programming language in disguise.
In my experience, these tools have another - counter intuitive and often overlooked - strength. Their limitations.
You want to handle this very specific edge case? With code, there is certainly a way to do this. It may take days, it may add unreasonable complexity. Nevertheless, someone (yourself?) will ask that this kinda insignificant edge case is properly handled. And won’t take no for an answer.
With a (too) limited « no code » tool, maybe there really is no way to handle the edge case (or it would require code in a context that forbids it). Management (or yourself!) has no way to make someone fix this, and can just give up. Soon enough, there is no problem. Finally, you can live with the unhandled edge case! Ok, you’ll just brief users. Ok they’ll learn by themselves that they shouldn’t do this.
So sometimes, « no code » tools can’t solve a problem. Then the problem simply disappear. It helps with finding a 80-20, something good enough. Everyone can be focused on more important stuff.
You want to handle this very specific edge case? With code, there is certainly a way to do this. It may take days, it may add unreasonable complexity. Nevertheless, someone (yourself?) will ask that this kinda insignificant edge case is properly handled. And won’t take no for an answer.
With a (too) limited « no code » tool, maybe there really is no way to handle the edge case (or it would require code in a context that forbids it). Management (or yourself!) has no way to make someone fix this, and can just give up. Soon enough, there is no problem. Finally, you can live with the unhandled edge case! Ok, you’ll just brief users. Ok they’ll learn by themselves that they shouldn’t do this.
So sometimes, « no code » tools can’t solve a problem. Then the problem simply disappear. It helps with finding a 80-20, something good enough. Everyone can be focused on more important stuff.
You may underestimate the ingenuity of non-developers hacking on no-code platforms. They end up thinking a lot more like developers than one might think.
Our operations organization has independently arrived at some things pretty darn adjacent to more advanced software patterns, like circuit breakers. (This being for workflow automation no-code tooling, vs website builders).
And a ton of real world work is getting done out there with Zapier, that's for sure.
Our operations organization has independently arrived at some things pretty darn adjacent to more advanced software patterns, like circuit breakers. (This being for workflow automation no-code tooling, vs website builders).
And a ton of real world work is getting done out there with Zapier, that's for sure.
I've seen a JSON parser written in a drag'n'drop visual no-code flowchart-like application that was very impressive and, if printed, would have caused the death of many trees. Utterly unmaintainable and horrifically stupid given any full-code solution would have involved using a pre-written library.
But then it's no longer no code. It's just a code environment for people who somehow got convinced "I could never learn to code".
There is no such thing. There are simply different representations of 'code'.
Those who promote 'no code' solutions always seem to think that just because one does not edit with a text editor that there is no need to design the solution or to debug it.
One is still developing, just using different tools.
For some subset of problems it might indeed enable someone who is not a programmer to create a solution just as Excel enabled millions of people to do just that. Unfortunately one usually finds a little later that the solution has the shape of the tools used to create it, that because the tool could do something in a certain way that is the way that is chosen rather than choosing the tool to fit the intended solution.
You end up with people creating databases in Excel because Excel is what they had.
Those who promote 'no code' solutions always seem to think that just because one does not edit with a text editor that there is no need to design the solution or to debug it.
One is still developing, just using different tools.
For some subset of problems it might indeed enable someone who is not a programmer to create a solution just as Excel enabled millions of people to do just that. Unfortunately one usually finds a little later that the solution has the shape of the tools used to create it, that because the tool could do something in a certain way that is the way that is chosen rather than choosing the tool to fit the intended solution.
You end up with people creating databases in Excel because Excel is what they had.
What is old is new again. This has happened before. Graphical programming, low-code, no-code. They all inevitably hit a wall where it does not cut it. Either the performance is not good enough, they need to dip into real code to add features, etc. Then there are the issues like CICD and version control that they don't do well that hold them back, and then integrating with the rest of the company. Its just not worth it, its a dream sold to VPs and will die off in a few years and come back a decade after that.
I previously was supporting a company integration with Appian (building the AWS/Webservices integrating the two halves), which bills itself as a Low Code platform for Business Process Management. And their hello world example kind of worked fine for getting "a business person" to "write code". So the idea was they get these business people to write code instead of developers. But the problem with this platform was that we had to eventually get full time software developers (so no cost savings there, but also had the issue of these devs were now niche developers and not learning broader skill sets). Because their graphical development didn't cut it, so they had to drop down into their code proprietary DSL. Then the actual platform was a mess of no cicd, bad disaster recovery, bad monitoring, bad everything. It would have been cheaper and easier to literally just write a business process management from scratch in whatever language we wanted.
tl;dr No code, low code, graphical programming is a fad.
I previously was supporting a company integration with Appian (building the AWS/Webservices integrating the two halves), which bills itself as a Low Code platform for Business Process Management. And their hello world example kind of worked fine for getting "a business person" to "write code". So the idea was they get these business people to write code instead of developers. But the problem with this platform was that we had to eventually get full time software developers (so no cost savings there, but also had the issue of these devs were now niche developers and not learning broader skill sets). Because their graphical development didn't cut it, so they had to drop down into their code proprietary DSL. Then the actual platform was a mess of no cicd, bad disaster recovery, bad monitoring, bad everything. It would have been cheaper and easier to literally just write a business process management from scratch in whatever language we wanted.
tl;dr No code, low code, graphical programming is a fad.
[deleted]
I agree completely. IPaaS tools are bad programming languages with awful tooling. The logic you need to transform some data, say, can become very complex quickly and you're stuck manipulating it with terrible graphical tools. When you inevitably find a bug, it's a huge pain to deal with.
For making a website with a store though, it can be great.
For making a website with a store though, it can be great.
>What do you think about this movement?
The "no-code" desire has been around for decades -- just using different terms. E.g. in 1980s and 1990s, a common phrase for new tools that didn't require programmers was "self-service" ... like Crystal Reports software for "self-service reports without programming".
To put it in perspective, consider that Microsoft Excel is a "no-code" tool. In the old days before desktop computers, if a business person wanted to look at a report of sales amounts grouped a different way, he would ask the COBOL programmers in the IT department for a "change request" and they'd do the following:
- "code" new punch cards for the mainframe: https://www.google.com/search?q=mainframe+punch+cards&source...
- load of magnetic tapes (each held about 40 megabytes) of the sales data: https://www.google.com/search?q=mainframe+9-track+tape&sourc...
- get a new report on greenbar paper: https://www.google.com/search?q=greenbar+paper&source=lnms&t...
Now, any office worker can do the above with a "no-code" tool like MS Excel with pivot tables, filters, etc. Even though Excel eliminates a lot of coding work, the demand for programmers keeps going up. No matter what "no-code" tool is invented, the world keeps inventing new tasks for human programmers to do that today's no-code tool can't do. There's always a delta in capabilities.
The "no-code" desire has been around for decades -- just using different terms. E.g. in 1980s and 1990s, a common phrase for new tools that didn't require programmers was "self-service" ... like Crystal Reports software for "self-service reports without programming".
To put it in perspective, consider that Microsoft Excel is a "no-code" tool. In the old days before desktop computers, if a business person wanted to look at a report of sales amounts grouped a different way, he would ask the COBOL programmers in the IT department for a "change request" and they'd do the following:
- "code" new punch cards for the mainframe: https://www.google.com/search?q=mainframe+punch+cards&source...
- load of magnetic tapes (each held about 40 megabytes) of the sales data: https://www.google.com/search?q=mainframe+9-track+tape&sourc...
- get a new report on greenbar paper: https://www.google.com/search?q=greenbar+paper&source=lnms&t...
Now, any office worker can do the above with a "no-code" tool like MS Excel with pivot tables, filters, etc. Even though Excel eliminates a lot of coding work, the demand for programmers keeps going up. No matter what "no-code" tool is invented, the world keeps inventing new tasks for human programmers to do that today's no-code tool can't do. There's always a delta in capabilities.
> No matter what "no-code" tool is invented, the world keeps inventing new tasks for human programmers to do that today's no-code tool can't do. There's always a delta in capabilities.
And by that logic always an opportunity to make something that was once hard to do, easy.
And by that logic always an opportunity to make something that was once hard to do, easy.
I hate it.
Some time (not long) ago I was working remotely on some software that was driven by an API on a remote server maintained by some folks in a different country. A long way from me.
Cutting a long story short I realised that the lack of control over the server was because they really did not know how it worked, or how to fix it or diagnose issues their server was having.
It was a laraval/MS-SQL system built from building blocks supplied by Microsoft. They wired all the blocks together in a GUI and look! It works!
* Putting images into a UU-encoded text field worked for images <7MB... The actual images the customers want are >10MB
* Low levels of activity it was reliable. Under load it randomly dropped sessions.
* They did not seem to know what logging was, or how to use it. I was supplying them with problem reports, carefully noting the time - and getting ghosted. I realised they had no way of knowing what their software was doing, or did. They could only set it up to do what they hoped.
* The stored times as wall clock time strings "2019-02-12T03:02:12.123" No time zone included. Time series data worth a lot of money. "What happens when daylight savings repeats an hour or skips one?" I asked. No answer. This infected the whole system. I spent a lot of time fighting dates, and was that in the past? Future? Is that supposed to be now?
Back in 1997 we had more reliable, and higher quality software, on a telehoused 486 Apache/Perl/Postgres system. But we compiled it from source and edited the configuration files by hand.
"No code" might be OK for Aunties cookie recipes, but for building infrastructure it is rot
Some time (not long) ago I was working remotely on some software that was driven by an API on a remote server maintained by some folks in a different country. A long way from me.
Cutting a long story short I realised that the lack of control over the server was because they really did not know how it worked, or how to fix it or diagnose issues their server was having.
It was a laraval/MS-SQL system built from building blocks supplied by Microsoft. They wired all the blocks together in a GUI and look! It works!
* Putting images into a UU-encoded text field worked for images <7MB... The actual images the customers want are >10MB
* Low levels of activity it was reliable. Under load it randomly dropped sessions.
* They did not seem to know what logging was, or how to use it. I was supplying them with problem reports, carefully noting the time - and getting ghosted. I realised they had no way of knowing what their software was doing, or did. They could only set it up to do what they hoped.
* The stored times as wall clock time strings "2019-02-12T03:02:12.123" No time zone included. Time series data worth a lot of money. "What happens when daylight savings repeats an hour or skips one?" I asked. No answer. This infected the whole system. I spent a lot of time fighting dates, and was that in the past? Future? Is that supposed to be now?
Back in 1997 we had more reliable, and higher quality software, on a telehoused 486 Apache/Perl/Postgres system. But we compiled it from source and edited the configuration files by hand.
"No code" might be OK for Aunties cookie recipes, but for building infrastructure it is rot
I don't like the idea, not because it doesn't work. It might, but in the mean time I lose ownership to my own code and tools. My code and tools might be shit, but at least they are well documented and I know how shit works. I prefer to play with my own shit than someone else's, if possible.
You may ask why then I don't write my own OS/IDE/Database/etc., well I'd love to but sadly I don't have the skills. I only do things within the boundary of my skills.
Sorry, ownership is No.1 issue for me.
You may ask why then I don't write my own OS/IDE/Database/etc., well I'd love to but sadly I don't have the skills. I only do things within the boundary of my skills.
Sorry, ownership is No.1 issue for me.
> What do you think about this movement?
It's not a movement, more like a mini-trend based on rediscovery of an old idea. At least not a pure investor duping like "metaverse".
> Clearly these apps/platforms enable non-developers to solve a bunch of problems which would otherwise need a software engineer. Is this a paradigm shift?
If it is, it happened in the last century and many times since then already. You could still hype it up for a new domain to grab some investor money, I guess.
It's not a movement, more like a mini-trend based on rediscovery of an old idea. At least not a pure investor duping like "metaverse".
> Clearly these apps/platforms enable non-developers to solve a bunch of problems which would otherwise need a software engineer. Is this a paradigm shift?
If it is, it happened in the last century and many times since then already. You could still hype it up for a new domain to grab some investor money, I guess.
I was wondering if there was any similar conversation going on way way back when compilers were a new thing - found this gem by Grace Hopper (1958) (yeah THAT Grace Hopper).
https://pubs.acs.org/doi/pdf/10.1021/ie50587a038
She's talking about the difference between "programmer" (one who designs logic and processes) from "coder" (one who converts those processes to "codes" - i.e. assembly) and how compilers have the potential to eliminate the need for "coders"
I'm tickled by the (IMO) obvious parallels that have just moved up a few levels in complexity us who use text editors to write programs are often supporting configurable logic for someone downstream who can get work done with less complexity using simpler, more accessible tools.
https://pubs.acs.org/doi/pdf/10.1021/ie50587a038
She's talking about the difference between "programmer" (one who designs logic and processes) from "coder" (one who converts those processes to "codes" - i.e. assembly) and how compilers have the potential to eliminate the need for "coders"
I'm tickled by the (IMO) obvious parallels that have just moved up a few levels in complexity us who use text editors to write programs are often supporting configurable logic for someone downstream who can get work done with less complexity using simpler, more accessible tools.
I first learned of Grace Hopper from a children's book I read to my kids.
Recently, I've been wondering what kinds of Hopperesque ease-of-coding advancements are still left to be invented. For example, are there advancements to made in syntax highlighting to make code read more like a natural language, and bugs easier to spot. (I'm explaining my thoughts poorly, text is the wrong medium).
Also: I Ctrl+F-ed "Grace" on the main page of this post knowing I'd find a hit.
Recently, I've been wondering what kinds of Hopperesque ease-of-coding advancements are still left to be invented. For example, are there advancements to made in syntax highlighting to make code read more like a natural language, and bugs easier to spot. (I'm explaining my thoughts poorly, text is the wrong medium).
Also: I Ctrl+F-ed "Grace" on the main page of this post knowing I'd find a hit.
I look at no-code as evolving to produce a high-level, (often visual) Domain Specific Language, with abstractions suited only to the problem domain.
Excel is the archetypal success-story, perhaps. It is ill-suited as a general purpose programming language, but as a language for arithmetic operations on data it... excels.
The same is true of Airtable and Zapier. They introduce new, simple abstractions for data, and for automation.
Disclosure: I'm the founder of a no-code startup in the browser automation space. I rationalise what we do as 'introducing high-level abstractions in a visual DSL'. You won't see that description in investor pitches. No-code products are just high-level programming languages.
If you pick the correct abstractions, working this way is actually faster than coding for the bulk of use-cases, whilst making edge-cases hard to deal with. For those, coding is inevitable.
Excel is the archetypal success-story, perhaps. It is ill-suited as a general purpose programming language, but as a language for arithmetic operations on data it... excels.
The same is true of Airtable and Zapier. They introduce new, simple abstractions for data, and for automation.
Disclosure: I'm the founder of a no-code startup in the browser automation space. I rationalise what we do as 'introducing high-level abstractions in a visual DSL'. You won't see that description in investor pitches. No-code products are just high-level programming languages.
If you pick the correct abstractions, working this way is actually faster than coding for the bulk of use-cases, whilst making edge-cases hard to deal with. For those, coding is inevitable.
My observation from running a consulting business is that there's a gap in the market that I have not seen meaningfully solved. On the one hand are these no-code tools where you can do something reasonable in a very limited domain. Wix, Squarespace, etc. Every decade the limited domain expands a bit, and you can get something serviceable for your hobby or small business fairly cheaply, in the order of $10s or $100s, maybe a couple thousand.
On the other hand, is full scale development, either in-house or outsourced. This is only doable for projects that are ~$50k and up, even if you go with cheap offshore developers.
So there's this gap from ~$5000 to $50,000 where if that's all you can afford, you just can't justify the project. In theory that's where the "low code" tools should fit, but so far, I have never seen it work out like that.
On the other hand, is full scale development, either in-house or outsourced. This is only doable for projects that are ~$50k and up, even if you go with cheap offshore developers.
So there's this gap from ~$5000 to $50,000 where if that's all you can afford, you just can't justify the project. In theory that's where the "low code" tools should fit, but so far, I have never seen it work out like that.
I have been a software engineer for a long time, C++ for the first half, and web development for the second. Recently I took a job as a contract developer for a large no code company. I had no idea what to expect and thought I was going to be limited to creating toy UI apps. I have been blown away at what I can accomplish in this platform. Virtually anything that can be done by a software engineer via languages like PHP (with some very definite exceptions / limits of course), Javascript, etc. can be done via the no code platform. Integrating with virtually any API takes seconds and they dont have to be pre built, I can essentially take any open api endpoint and get and send data to in in a minute (after I understand the API parameters, etc.) SSO integration, Parsing JSONS, complex data filtering, database queries, creating forms, saving data, creating work flow processes, relatively complex server side calculations, you name it, it can be done. It allows for the use of excel and lodash functions as well against data although that is pushing the "No Code" concept, Essentially anything I have done in my prior web development work, I can do on this platform. Some things take a little figuring out and there are some lengthy chaining of components but it works. No code is not a toy anymore, it is a legit technology and while it definitely takes some engineer level thinking sometimes, it very much works.
Can you suggest some tools that you really like in this space? You got me intrigued about automatically integrating an API. I want to do this + small amounts of scraping for side projects but even as a 'developer' I cannot drag myself to start the IDE after hours so many project ideas just languish in the back of my head.
EDIT: oh sorry you posted the response just as soon as I posed this question. What a coincidence!
EDIT: oh sorry you posted the response just as soon as I posed this question. What a coincidence!
Sounds a lot like the platform i've been working in for the last year or so (coming from a pretty hard code software engineering background for the last 15 years) and continually finding it surprisingly capable. Do you mind to share the name of the platform?
---Redacted---
Darn, it seems like they are not something a regular consumer can just buy and use. Guessing something that good wouldn't be appropriate for consumer environments. :/
I'm a backend focused engineer that's worked on PHP and Javascript API / apps. In the past I had to write a lot of boilerplate code, now things like Strapi make it super easy to prototype data models and give you authenticated APIs for very little effort.
I'm a huge fan of Plasmic so far, I've tried to make frontend react sites and they don't look as nice as what I'm able to achieve with what I can only call a "website builder" tool.
My goal is to customize the CMS and use it as an API for a separate frontend site. JAMStack is the future... I don't think there is anything specifically 'no-code' about it but I'm suggesting two tools here that let you do no-code and also have nice doorhandles to let you get under the hood. I think that last part is key.
I'm a huge fan of Plasmic so far, I've tried to make frontend react sites and they don't look as nice as what I'm able to achieve with what I can only call a "website builder" tool.
My goal is to customize the CMS and use it as an API for a separate frontend site. JAMStack is the future... I don't think there is anything specifically 'no-code' about it but I'm suggesting two tools here that let you do no-code and also have nice doorhandles to let you get under the hood. I think that last part is key.
It's in the same class of ideas as perpetual motion machines.
In that case, it violates laws of thermodynamics, in the "no code" case, it violates Information Theory.
The entire process of coding is about translating requirements into machine executable programs. The requirements cannot be condensed below a certain threshold and that's where the 'no code' promise fails. You can move around blocks of shapes but in the end they must represent the same amount of information and it just resembles code.
In that case, it violates laws of thermodynamics, in the "no code" case, it violates Information Theory.
The entire process of coding is about translating requirements into machine executable programs. The requirements cannot be condensed below a certain threshold and that's where the 'no code' promise fails. You can move around blocks of shapes but in the end they must represent the same amount of information and it just resembles code.
Yes. People can make wonderful things on computers. Online satellite maps, GPT3 text generators, simulated 3-D universes.
But never a successful no-code system.
But never a successful no-code system.
The fundamental problem with any no-code type solution is balancing how complicated the system is. If a no-code system is too simple, then you'll need a programmer whenever you need to do something not offered by the no-code system. If it's too complicated, then you might as well just use an actual programming language.
Obviously, there are use cases for these type of systems. Many businesses only need a simple website, and there are a lot of problems out there where an off the shelf solution will suffice. However, I doubt no-code is going to make any meaningful impact on software development. The world is full of problems too complicated to solve with off the shelf solutions, and those problems will need a programmer to write some code.
Obviously, there are use cases for these type of systems. Many businesses only need a simple website, and there are a lot of problems out there where an off the shelf solution will suffice. However, I doubt no-code is going to make any meaningful impact on software development. The world is full of problems too complicated to solve with off the shelf solutions, and those problems will need a programmer to write some code.
I don't see the 'no-code' movement as something new, just a new name on the same idea. Developers are expensive, so let's migrate this work to people who cost less, using tools that provide the same or similar value.
Do you know how many people's jobs today are "this person is really good with excel, so we can hold on hiring a dev team and data scientist"? Probably millions. They're everywhere. I met dozens of them hidden away in Amazon warehouses during my career there. And Excel is the ultimate 'no-code' tool, pinnacle of the industry.
And yet the developers, we're all still here. Frankly, there's more of us. Because what really happens when you don't need developers to do the simple stuff is that developers can instead focus on the hard, higher-value problems, that a no-code solution can't do for you. More gets done, more value gets created.
There's always talk that eventually, we'll reach the end of the runway and the no-code will replace are large portion of us. I don't think we're anywhere near that. So bring on your no-code products, I say.
Do you know how many people's jobs today are "this person is really good with excel, so we can hold on hiring a dev team and data scientist"? Probably millions. They're everywhere. I met dozens of them hidden away in Amazon warehouses during my career there. And Excel is the ultimate 'no-code' tool, pinnacle of the industry.
And yet the developers, we're all still here. Frankly, there's more of us. Because what really happens when you don't need developers to do the simple stuff is that developers can instead focus on the hard, higher-value problems, that a no-code solution can't do for you. More gets done, more value gets created.
There's always talk that eventually, we'll reach the end of the runway and the no-code will replace are large portion of us. I don't think we're anywhere near that. So bring on your no-code products, I say.
When these things pop up again for the umpteenth time I just refer people to the classic text on the subject.
Fred Brooks essay "No Silver Bullet"
http://worrydream.com/refs/Brooks-NoSilverBullet.pdf
Fred Brooks essay "No Silver Bullet"
http://worrydream.com/refs/Brooks-NoSilverBullet.pdf
I'm in the process of doing a technical audit of several of these for a government. My favourite so far is the ServiceNow platform.
These platforms are great at making use of bottom tier devs quite effectively. They're a resource amplifier, when you don't have the cash to hire better devs. Hire a few devs to create the custom controls, actions, etc.. and have a boat load of juniors implement the requirements. Most of these folk haven't picked up a new language since college, and don't incorporate coding into their lives. These individuals have value, but often create more problems due to their lack of skill and/or experience. In a low/no code environment, you can better ensure that they're on rails.
The issues we're encountering is the pricing model, and it's most likely we'll end up going with Microsoft's because of the existing contracts. ServiceNow for all it's strengths really shoots itself in the foot with pricing. A product like this benefits from any "power" user being able to implement their own internal workflows, but ServiceNow charges per dev. So they're handicapping themselves. But someone will figure out all the pieces, it's inevitable.
As a means to solve boring, repetitive, uninspired development, it's great, and it'll be the future in the way that SquareSpace and Wix ate into front end presence sites...
And honestly, if you aren't a great developer, I suspect the rails would make you feel a lot better.
This won't take any jobs from anyone likely reading this. HN frequently has a blind spot for that vast majority of enterprise development. It's not sexy, but it makes up more developers than the Silicon Valley crowd by magnitudes. And most of them would fail a Fizz Buzz. With no code, I can make use of those resources.
These platforms are great at making use of bottom tier devs quite effectively. They're a resource amplifier, when you don't have the cash to hire better devs. Hire a few devs to create the custom controls, actions, etc.. and have a boat load of juniors implement the requirements. Most of these folk haven't picked up a new language since college, and don't incorporate coding into their lives. These individuals have value, but often create more problems due to their lack of skill and/or experience. In a low/no code environment, you can better ensure that they're on rails.
The issues we're encountering is the pricing model, and it's most likely we'll end up going with Microsoft's because of the existing contracts. ServiceNow for all it's strengths really shoots itself in the foot with pricing. A product like this benefits from any "power" user being able to implement their own internal workflows, but ServiceNow charges per dev. So they're handicapping themselves. But someone will figure out all the pieces, it's inevitable.
As a means to solve boring, repetitive, uninspired development, it's great, and it'll be the future in the way that SquareSpace and Wix ate into front end presence sites...
And honestly, if you aren't a great developer, I suspect the rails would make you feel a lot better.
This won't take any jobs from anyone likely reading this. HN frequently has a blind spot for that vast majority of enterprise development. It's not sexy, but it makes up more developers than the Silicon Valley crowd by magnitudes. And most of them would fail a Fizz Buzz. With no code, I can make use of those resources.
I asked this a few hours ago here: https://news.ycombinator.com/item?id=29187754
Here's my take, quoted from my thread:
I've slowly started appreciating the nocode / low-code movement. At first: I thought it was a lazy person's dream, but more and more I realize a lot of the low hanging fruit that you can do with code has been done and there's little left to make. I mean, why bother re-invent the wheel right? So now I just leverage software made by other people typically GUIs / point-and-click tools and a bunch of online services to automate burdensome tasks.
I still write simple one-liner helper scripts in my free time though, typically userscripts that I place into Tampermonkey/Violentmonkey to automate a bunch of stuff and make the web more accessible. I call this 'low code' so I'm not entirely reliant on GUIs.
What's your thought on the movement? Do you like the term 'nocode'?
Here's my take, quoted from my thread:
I've slowly started appreciating the nocode / low-code movement. At first: I thought it was a lazy person's dream, but more and more I realize a lot of the low hanging fruit that you can do with code has been done and there's little left to make. I mean, why bother re-invent the wheel right? So now I just leverage software made by other people typically GUIs / point-and-click tools and a bunch of online services to automate burdensome tasks.
I still write simple one-liner helper scripts in my free time though, typically userscripts that I place into Tampermonkey/Violentmonkey to automate a bunch of stuff and make the web more accessible. I call this 'low code' so I'm not entirely reliant on GUIs.
What's your thought on the movement? Do you like the term 'nocode'?
I have a relative who's been programming since forever (although he would never call himself a programmer), and he talks about the first time he saw FORTRAN IV. Finally there was a language where you didn't have to be a programmer or know about computers to use. You just typed in what you wanted the computer to do and it did it. You could solve your own problems without having to wait for the programmers to do it for you. So clearly the desire to get "programming" out of the exclusive domain of programmers is hardly a new thing.
Visual no-code/low-code tools have been around for decades. They can work really well when they are aimed at a manageable sized domain (e.g. data wrangling). They tend to fail badly when the try to be a replacement for a general purpose programming language.
I think a lot of the problem is the endless hype and over-promising by marketing and sales people.
I think a lot of the problem is the endless hype and over-promising by marketing and sales people.
Platforms like Alteryx (https://www.alteryx.com/) used for large data cleaning strike me as a strange stop gap between a clunky system like Excel (which has its natural 1 million row limit) and Python/R/SQL that are full OOP and are likely considered too hard to learn for many business professionals. And yet watching people using the platform looks tortuous! Why not invest in an often free application that you can fully control instead of buying an expensive, no-code based application? Likely has to do with what allows you to maintain talent / not pay for 'programmer' up front in salary costs.
I'm a decent programmer and I use an expensive, no-code application called FME for data cleaning/analysis/exploration/transformation etc. almost all the time. While I'm certainly capable doing basically everything I do in FME using Python, I am far more productive using FME. With FME I can knock together something in 10-15 minutes that would take me hours to do in Python.
That being said, one feature of FME that I do use a lot is that at any point you can drop in a PythonCaller which lets you execute arbitrary python code on your data. Invaluable for the last 5-10% which cannot easily be done using the "no code" approach
That being said, one feature of FME that I do use a lot is that at any point you can drop in a PythonCaller which lets you execute arbitrary python code on your data. Invaluable for the last 5-10% which cannot easily be done using the "no code" approach
The combination of visual programming with the ability to add code when required can be very fast and powerful (it is the approach we are using with our data cleaning tool, Easy Data Transform).
They need to stop locking people into their ecosystem and generate code you can get out and hand out to a developer if necessary.
No-Code / Low-Code / Full-Code is a false trichotomy anyway. There's no reason why visual coding needs to be any more restricted than the real deal.
It's all just one big usability problem. We'll continue to develop software pretending we're running 80 character wide terminals for awhile, but I believe this will change someday.
Tools like Enso, or the Elm debugger already show how much better things are with instant, actionable feedback, even on "real" languages. Then you remember Smalltalk and HyperCard existed in the 80s and you wonder how it all went so wrong.
No-Code / Low-Code / Full-Code is a false trichotomy anyway. There's no reason why visual coding needs to be any more restricted than the real deal.
It's all just one big usability problem. We'll continue to develop software pretending we're running 80 character wide terminals for awhile, but I believe this will change someday.
Tools like Enso, or the Elm debugger already show how much better things are with instant, actionable feedback, even on "real" languages. Then you remember Smalltalk and HyperCard existed in the 80s and you wonder how it all went so wrong.
I think if someone made a decent auto-fullstack-web-CRUD app they would be very rich and would have solved a lot of no-code problems and saved us an amazing number of man-hours on internal tools.
Just: SQL tables, prettified CRUD on those SQL tables on the frontend (with R/W permissions per user on tables), and reports (either on-the-fly or SQL queries run on a cron schedule).
Just: SQL tables, prettified CRUD on those SQL tables on the frontend (with R/W permissions per user on tables), and reports (either on-the-fly or SQL queries run on a cron schedule).
We're (https://www.wax.run/) doing this. We expose a CRUD app for your existing database in Google Sheets. You can also call custom Python for anything not covered by SQL.
Isn't that just basically Rails? It has a (pretty good) built-in ORM, prettified CRUD on any of the tables managed through that ORM and making SQL queries on a cron schedule is possible through Rake tasks, which come preinstalled with the framework.
JHipster (https://www.jhipster.tech/) goes a bit beyond that. From my reading, its basic functionality is taking in either interactive command line inputs or theor custom DSL, and spitting out DDL for a MySQL DB, Spring Boot backend, and Angular frontend.
> Just: SQL tables, prettified CRUD on those SQL tables on the frontend (with R/W permissions per user on tables), and reports (either on-the-fly or SQL queries run on a cron schedule).
Supabase is pretty much the backend piece of this (built around PostgREST), all it needs is a frontend generator that fits with its DB conventions.
Supabase is pretty much the backend piece of this (built around PostgREST), all it needs is a frontend generator that fits with its DB conventions.
Lots of startups attempting this, two big ones being Retool and Airtable doing almost exactly what you describe.
Ms-Access says Hello :)
> Ms-Access says Hello :)
You mean Sharepoint. oh wait, it sucks! ...
You mean Dreamweaver. Oh wait, it produces crappy code ...
Visual FoxPro...
VBA apps...
Java's Vignette...
Who the hell are people kidding here? I encourage all the "no-code" people here to try all these solutions and understand why they eventually failed, because yours will suffer from the exact same problems...
You mean Sharepoint. oh wait, it sucks! ...
You mean Dreamweaver. Oh wait, it produces crappy code ...
Visual FoxPro...
VBA apps...
Java's Vignette...
Who the hell are people kidding here? I encourage all the "no-code" people here to try all these solutions and understand why they eventually failed, because yours will suffer from the exact same problems...
Background I have worked at a low code/ no code shop. We could deliver prototypes fast. But that’s just it they were prototypes that went into production but at that point clients were hooked just where you want them. At that point feature requests require one of two things. A coder to build a new no code widget or more likely just code the feature. So to summarize they make the easy things easy but the hard things impossible. As time goes on maybe you have enough widgets to be successful but most problems are one offs where the widget is only needed once so why build the widget when coding is faster and cheaper?
I mean, what is programming? It’s describing the rules of a system and all edge cases. For some stuff it makes sense to combine rule descriptions into Lego blocks. At some point, the Lego blocks become too big to be useful and you need fine-grained control over the rules you want to implement.
If you can combine big Lego blocks into something useful, that sounds great.
If you need more fine-grained control, you need smaller blocks.
And that is the spectrum from assembly to higher level languages to platforms to libraries to frameworks to low-code tools to no-code tools. Pick what works for your use-case.
If you can combine big Lego blocks into something useful, that sounds great.
If you need more fine-grained control, you need smaller blocks.
And that is the spectrum from assembly to higher level languages to platforms to libraries to frameworks to low-code tools to no-code tools. Pick what works for your use-case.
The first successful no-code platform(VisiCalc) came out in 1979 so calling it a new movement or innovation is just people being ignorant about the past.
In essence this is an old Idea that have been on the cusp of making the professional application developer obsolete since COBOL was invented back in 1959.
There is a cyclic nature to this and at i don't see any real difference in this generation of tools then something like SAP ABAP in that it will not also develop into a new sub-specialization that Leeds to an increase in the need for full time programmers.
In essence this is an old Idea that have been on the cusp of making the professional application developer obsolete since COBOL was invented back in 1959.
There is a cyclic nature to this and at i don't see any real difference in this generation of tools then something like SAP ABAP in that it will not also develop into a new sub-specialization that Leeds to an increase in the need for full time programmers.
While I certainly saw them coming a mile away, the rise of sites like Squarespace and Wix still unnerves me a little bit.
While I do primarily backend data work these days, I spent a lot of the early 2000's working for an agency that built websites for people and companies. Many of which would have been simple enough to throw together in Squarespace.
I'd always thought I could fall back into building websites if this didn't work out, but I feel like that's falling out as my backup plan. I still try to keep up on CSS and JS though, just incase.
While I do primarily backend data work these days, I spent a lot of the early 2000's working for an agency that built websites for people and companies. Many of which would have been simple enough to throw together in Squarespace.
I'd always thought I could fall back into building websites if this didn't work out, but I feel like that's falling out as my backup plan. I still try to keep up on CSS and JS though, just incase.
I feel you.
I freelanced designing and building websites in the '00s before gradually migrating into in-house creative direction and product design. After getting burned out doing that, I've tried to start a little solo web and brand shop again, which sounds fun on paper, but I can't find a market for it. People just want inexpensive Squarespace editors. They look to Fiverr, Upwork, etc.
It reminds me of the Wordpress-only shops that drove me to in-house/product design in the first place, but with even less custom work being done.
It's a loss for web as a creative platform, and has left me unsure of how to proceed professionally.
I freelanced designing and building websites in the '00s before gradually migrating into in-house creative direction and product design. After getting burned out doing that, I've tried to start a little solo web and brand shop again, which sounds fun on paper, but I can't find a market for it. People just want inexpensive Squarespace editors. They look to Fiverr, Upwork, etc.
It reminds me of the Wordpress-only shops that drove me to in-house/product design in the first place, but with even less custom work being done.
It's a loss for web as a creative platform, and has left me unsure of how to proceed professionally.
I see it as kind of comforting. These tools take care of the cookie-cutter projects so developers can work on more interesting things.
No Code can solve problems that have been solved so many times before that a bunch of developers decided there was money in solving the entire class of problems once and for all.
So I think they are great, because who wants to reinvent the wheel? It's so much nicer to pay someone else to deal with the problem while I focus on building solutions to novel problems.
Is it a paradigm shift? Yes, in the same way that Excel was a paradigm shift. When you make it easier to solve a class of problems, then people solve more problems in that domain.
Excel radically transformed so many industries because it suddenly became dirt cheap to do complex costs analysis, so instead of paying an accounting firm to run two or three various costs analysis for a product, they could instead be paid to find the optimal solution for a product to hit a specific price point. Suddenly, we have candy bars with 54.51g of chocolate in them.
Something to keep in mind, is when the cost to compete in a segment goes down, competition increases to the point where the cost to compete is driven back up. If anyone can build a competing product in a weekend with 0 background, then competing products are going to pop up where ever money is being made. And one of those competitors is going to innovate their way to the top, through technology, marketing, corruption, or some other means.
So I think they are great, because who wants to reinvent the wheel? It's so much nicer to pay someone else to deal with the problem while I focus on building solutions to novel problems.
Is it a paradigm shift? Yes, in the same way that Excel was a paradigm shift. When you make it easier to solve a class of problems, then people solve more problems in that domain.
Excel radically transformed so many industries because it suddenly became dirt cheap to do complex costs analysis, so instead of paying an accounting firm to run two or three various costs analysis for a product, they could instead be paid to find the optimal solution for a product to hit a specific price point. Suddenly, we have candy bars with 54.51g of chocolate in them.
Something to keep in mind, is when the cost to compete in a segment goes down, competition increases to the point where the cost to compete is driven back up. If anyone can build a competing product in a weekend with 0 background, then competing products are going to pop up where ever money is being made. And one of those competitors is going to innovate their way to the top, through technology, marketing, corruption, or some other means.
Yeah, I tried to get on this wave of (no|low)-code to enable non-devs to prototype their ideas. Turns out they run into "counter-intuitive" things when modeling your data and ones mental models have to be redeveloped.. and the query languages (like bubble) get pretty abstract fast. Future AI driven prototyping may be interesting. For now lets get back to "medium-code": rails, django, airtable/baserow, canonic, firebase, etc.
As an SE, I think that no-code is great. It lets us focus on the more interesting and challenging problems. Here's how we approached that in my current start-up.
We built the website on Squarespace ( a tiny bit of custom JS because I wanted a specific UX, but minor). When we are fully launched and selling product, we'll probably continue to use squarespace, but we'll see. It suits us for marketing purposes and capturing interest now.
At the same time, we're working in the hardware space (healthtech building an EEG), so we write all of our firmware, and we've got AI running on google cloud, so all the data pipelines that go along with that.
We're building the front-end for our mobile app, but using Google Firebase for the user account, and other simple user-data stuff that we need. I consider Firebase to be mostly no-code, I code up the front-end, but don't need to do anything on the backend.
The more interesting thing I've heard of recently is Fl{0} (https://fl0.com). They're a Sydney based start-up that is building a low-code style backend system. I'm not completely sure I get it, maybe it's just another version of nodeRed, and other similar tools.
We built the website on Squarespace ( a tiny bit of custom JS because I wanted a specific UX, but minor). When we are fully launched and selling product, we'll probably continue to use squarespace, but we'll see. It suits us for marketing purposes and capturing interest now.
At the same time, we're working in the hardware space (healthtech building an EEG), so we write all of our firmware, and we've got AI running on google cloud, so all the data pipelines that go along with that.
We're building the front-end for our mobile app, but using Google Firebase for the user account, and other simple user-data stuff that we need. I consider Firebase to be mostly no-code, I code up the front-end, but don't need to do anything on the backend.
The more interesting thing I've heard of recently is Fl{0} (https://fl0.com). They're a Sydney based start-up that is building a low-code style backend system. I'm not completely sure I get it, maybe it's just another version of nodeRed, and other similar tools.
From what I've seen close-up in the indiehacker community, it's shifted the goal-posts of what an MVP is.
You used to be able to get away with a landing page with just a form to collect email addresses - now you need a hell of a lot more polish to get started.
You used to be able to get away with a landing page with just a form to collect email addresses - now you need a hell of a lot more polish to get started.
No-code is always doomed to fail because the forefront of development always requires complex reasoning and understanding of leaky abstractions. I worked at one point with a business rules engine, and non-programmers are fine with a decision tree, but start introducing loops, queues, function calls with multiple parameters, database queries, or even complex logic in if statements and it gets hairy. It takes training to reason like that.
It doesn't matter how nice the UI is, there's a fundamental level of complexity there that requires study and training that also induces anxiety in an untrained person.
No-code can handle a significant percentage of work. In the system I experienced ten years ago I would guess 20-30%? In that case, we had close collaboration between developers and business people within the same building, and some of the business people were even willing to be trained in SQL (!). It's certainly useful in that regard, but it doesn't eliminate the custom stuff. The eventual interactions between the custom and no-code logics are something that requires balancing too.
It doesn't matter how nice the UI is, there's a fundamental level of complexity there that requires study and training that also induces anxiety in an untrained person.
No-code can handle a significant percentage of work. In the system I experienced ten years ago I would guess 20-30%? In that case, we had close collaboration between developers and business people within the same building, and some of the business people were even willing to be trained in SQL (!). It's certainly useful in that regard, but it doesn't eliminate the custom stuff. The eventual interactions between the custom and no-code logics are something that requires balancing too.
Bret Victor has ideas. https://youtu.be/8pTEmbeENF4
There is a fundamental tension between “what computers understand how to do” and “the problems that humans are trying to solve with computers.”
Every programming language lies somewhere between one of these two fixed points. The goal of many if not most programmers is to end up with a system that lets you express all of your domain-specific problems as clearly as possible, abstracting away the fiddly bits that you don’t care about.
There’s a lot of stuff that has to exist in order to get to that level, and we neither agree about it nor know all of what it entails for any specific thing. So Domain Specific Languages (DSLs) are often the best that we can do, and they vary wildly in quality.
Some DSLs lend themselves to being visually programmed. They tend to be rare and niche, and incredibly helpful to the people who can use them. Perhaps more is possible, but it requires a foundation to build upon that does not yet universally or even commonly exist, and may never exist.
There is a fundamental tension between “what computers understand how to do” and “the problems that humans are trying to solve with computers.”
Every programming language lies somewhere between one of these two fixed points. The goal of many if not most programmers is to end up with a system that lets you express all of your domain-specific problems as clearly as possible, abstracting away the fiddly bits that you don’t care about.
There’s a lot of stuff that has to exist in order to get to that level, and we neither agree about it nor know all of what it entails for any specific thing. So Domain Specific Languages (DSLs) are often the best that we can do, and they vary wildly in quality.
Some DSLs lend themselves to being visually programmed. They tend to be rare and niche, and incredibly helpful to the people who can use them. Perhaps more is possible, but it requires a foundation to build upon that does not yet universally or even commonly exist, and may never exist.
Its a shift in some ways. Lowers a lot of friction for prototyping and production purposes for plenty of adhoc tools. People think this will help. It does and it will. I've used quite a bit of it and had generally good results. We're only in the early stages even though plenty of tools are a decade old.
But it has limits like everything else. Vendor lock-in is returning similar to the old days of mainframes. But at least this time around the tools are more varied and from different vendors as well as the ability to use one of many languages in most cases.
You can run a bunch of businesses with writing very little code. What they don't seem to include in that no-code advertising blurb is the amount of configuration required for some no-code solutions. Especially integrating each *aaS to the next. That seems trivial but can become quite a project.
The bigger cloud offerings such as AWS create dependencies that might be an issue for a lot of businesses if they try to switch. This includes wanting on-premises solutions for whatever reason instead of the cloud. AWS is more than "hey you can run redis, mysql etc in the cloud". Its constellation of convenience is quite a thing to behold. Gets hard to leave. That's the new variant of the old vendor lock-in strategy: You don't want to leave and it can hurt a lot to do so.
There is also an issue with non-cloud alternatives as inherent to most of the no-code solutions in practical use. Unless of course you have a disaster recovery plan for when your favorite sites go down. We still need to have DR plans even for no-code.
You are ready for the no-code platforms you use to go offline, right?
Haven't mentioned security. Better not forget that either.
No-code means more contract management.
But it has limits like everything else. Vendor lock-in is returning similar to the old days of mainframes. But at least this time around the tools are more varied and from different vendors as well as the ability to use one of many languages in most cases.
You can run a bunch of businesses with writing very little code. What they don't seem to include in that no-code advertising blurb is the amount of configuration required for some no-code solutions. Especially integrating each *aaS to the next. That seems trivial but can become quite a project.
The bigger cloud offerings such as AWS create dependencies that might be an issue for a lot of businesses if they try to switch. This includes wanting on-premises solutions for whatever reason instead of the cloud. AWS is more than "hey you can run redis, mysql etc in the cloud". Its constellation of convenience is quite a thing to behold. Gets hard to leave. That's the new variant of the old vendor lock-in strategy: You don't want to leave and it can hurt a lot to do so.
There is also an issue with non-cloud alternatives as inherent to most of the no-code solutions in practical use. Unless of course you have a disaster recovery plan for when your favorite sites go down. We still need to have DR plans even for no-code.
You are ready for the no-code platforms you use to go offline, right?
Haven't mentioned security. Better not forget that either.
No-code means more contract management.
The hype around no-code is manufactured and financed by the VC-backed companies in that space. Webflow is probably the biggest culprit, no other company attempts to pretend that a modern Dreamweaver (with all kinds of CMS lock-in under the hood) is going to revolutionize web design.
Other types of no-code tools span the entire gamut of IT, sales and marketing workflows. You already mentioned Zapier which for me has been very useful for a niche use case. I was setting up a virtual conference that used one app for selling tickets and accepting payment, and a second Zoom-like app that would host the livestream. I needed a way to automatically send event registrants an email from the livestream app with their conference link. Zapier did this very easily.
Another type of no-code tool that's pretty common is something like Google Tag Manager. Instead of needing developers to set up custom tag snippets in page templates, you can just add one GTM tag, then use a web GUI to add in additional tags. No access required to the production site.
Other types of no-code tools span the entire gamut of IT, sales and marketing workflows. You already mentioned Zapier which for me has been very useful for a niche use case. I was setting up a virtual conference that used one app for selling tickets and accepting payment, and a second Zoom-like app that would host the livestream. I needed a way to automatically send event registrants an email from the livestream app with their conference link. Zapier did this very easily.
Another type of no-code tool that's pretty common is something like Google Tag Manager. Instead of needing developers to set up custom tag snippets in page templates, you can just add one GTM tag, then use a web GUI to add in additional tags. No access required to the production site.
> Clearly these apps/platforms enable non-developers to solve a bunch of problems which would otherwise need a software engineer.
I'm not sure that's as clear as it seems at first. Everywhere I've been involved with them, the flow is like this:
1) Org sold on idea of no/low code tool, "business analyst can build things!" 2) Business analyst tries, fails to build things, calls dev 3) Dev figures it out, could have done similar in a few lines of code. Either a) becomes "expert" in tool or b) goes back to code
I'm not ready to rule them all out, and maybe I just worked with some inept business analysts. These tools are by their nature usually closed source/proprietary, but maybe there's some great ones. But I also wonder if it's not partially fundamental: maybe text is just more concise and expressive than visual paradigms for some problems - there's a reason we still have textbooks for some things.
I'm not sure that's as clear as it seems at first. Everywhere I've been involved with them, the flow is like this:
1) Org sold on idea of no/low code tool, "business analyst can build things!" 2) Business analyst tries, fails to build things, calls dev 3) Dev figures it out, could have done similar in a few lines of code. Either a) becomes "expert" in tool or b) goes back to code
I'm not ready to rule them all out, and maybe I just worked with some inept business analysts. These tools are by their nature usually closed source/proprietary, but maybe there's some great ones. But I also wonder if it's not partially fundamental: maybe text is just more concise and expressive than visual paradigms for some problems - there's a reason we still have textbooks for some things.
Good examples of no-code (relative to the things they replace because a good no-code solution degrades gracefully into code/abstraction it replaces for complex cases):
- spreadsheets :: textbook example
- OS/file systems :: it is hard to imagine times without it, when these operations had to be programmed manually
- relational DBs/SQL :: compared to myriads of ways data manipulation was programmed previously
- shell pipeline :: compared to manipulating processes directly in C. People can be tricked into writing useful shell commands without thinking about themselves as programmers.
There are many [less general] domain-specific examples such as GraphEdit, GUI/web-site builders, yahoo pipes, labview, etc.
Declarative configs for various things (even if they literally called "code" can be also considered no-code solutions e.g., IAAC) or various DSLs that discourage the general code with loops/ifs (even if it is Turing complete formally).
- spreadsheets :: textbook example
- OS/file systems :: it is hard to imagine times without it, when these operations had to be programmed manually
- relational DBs/SQL :: compared to myriads of ways data manipulation was programmed previously
- shell pipeline :: compared to manipulating processes directly in C. People can be tricked into writing useful shell commands without thinking about themselves as programmers.
There are many [less general] domain-specific examples such as GraphEdit, GUI/web-site builders, yahoo pipes, labview, etc.
Declarative configs for various things (even if they literally called "code" can be also considered no-code solutions e.g., IAAC) or various DSLs that discourage the general code with loops/ifs (even if it is Turing complete formally).
Someday it might happen, but the problem is being specific enough:
https://i.redd.it/s140v80nmc561.png
https://i.redd.it/s140v80nmc561.png
We see a novel use case around low/no code.
We hire engineers (usually ML, computer visions, etc.) and embed them with clients.
They meet 1-1 with their team members to walk through what they actually do in their daily work.
The eng. can then build light-weight solutions in real-time to optimize & automate those workflows.
It’s like prototyping as a service.
There’s certainly a huge movement around “citizen developers,” but what we’ve seen is these makers get stuck quickly when their solutions need to scale, be used by someone else, or integrate with other workflows.
Computational thinking is the key.
Initially we thought, like everyone else, we’d hire no coders and teach them to think like engineers.
It became obvious quickly that is was more about finding product-minded engineers who enjoy building things that help people and then show them how fast they could do that with these tools.
It’s made us incredibly opinionated about no code tools. Most are too limited for this approach.
We hire engineers (usually ML, computer visions, etc.) and embed them with clients.
They meet 1-1 with their team members to walk through what they actually do in their daily work.
The eng. can then build light-weight solutions in real-time to optimize & automate those workflows.
It’s like prototyping as a service.
There’s certainly a huge movement around “citizen developers,” but what we’ve seen is these makers get stuck quickly when their solutions need to scale, be used by someone else, or integrate with other workflows.
Computational thinking is the key.
Initially we thought, like everyone else, we’d hire no coders and teach them to think like engineers.
It became obvious quickly that is was more about finding product-minded engineers who enjoy building things that help people and then show them how fast they could do that with these tools.
It’s made us incredibly opinionated about no code tools. Most are too limited for this approach.
It's always been a pipe dream. I wish that people would invest more into making decent real SDKs for full developers to use instead of chasing this fantasy that you're going to be able to solve all your problems by gluing pre-made lego blocks together.
What invariably happens is that somebody gets a bee in their ear about some silver-bullet low-code tool, and tries to use it. They maybe get a few simple work-flows to work. Then they try to start doing more complex things, and it falls apart rapidly. Then more requirements are foisted onto the low-code platform, and developers get dragged in to try to build integrations into it and new custom components for it. Usually this is unbelievably awful to do.
Eventually you have developers having to maintain this awful Rube Goldberg machine of crap that they didn't want to be involved in,
What invariably happens is that somebody gets a bee in their ear about some silver-bullet low-code tool, and tries to use it. They maybe get a few simple work-flows to work. Then they try to start doing more complex things, and it falls apart rapidly. Then more requirements are foisted onto the low-code platform, and developers get dragged in to try to build integrations into it and new custom components for it. Usually this is unbelievably awful to do.
Eventually you have developers having to maintain this awful Rube Goldberg machine of crap that they didn't want to be involved in,
I think what we're seeing is what we've always seen. That is, we start at the lowest levels and continuously work towards a higher and higher level. Constantly making the development process more efficient. No-code solves a problem, but it's not a panacea.
The movement i'm most interested in as a backend developer is the no-software movement.
The idea that the entire process of developing and deploying services can take place in the browser. Why install an IDE when i can just code in a browser. Why install git when i can press a button in the browser and have it handled in the cloud. Why run the code locally when i can run it in the cloud and stream the output to the browser. Why install a bunch of software and configure everything to work on my machine, when it can all be handled in the cloud and interfaced via the browser.
The movement i'm most interested in as a backend developer is the no-software movement.
The idea that the entire process of developing and deploying services can take place in the browser. Why install an IDE when i can just code in a browser. Why install git when i can press a button in the browser and have it handled in the cloud. Why run the code locally when i can run it in the cloud and stream the output to the browser. Why install a bunch of software and configure everything to work on my machine, when it can all be handled in the cloud and interfaced via the browser.
You don't need to learn to code, and neither do your kids.
I'm a Software Developer, but I don't see why everyone should have to, or feel like they have to, learn to code.
In general, kids and adults alike, but especially kids, should spend more time being active, around others (within reason, these are extraordinary times), and outside - not in front of computer screens.
Not everyone is cut out for or interested in coding, just like not everyone is cut out for or interested in medicine, law, a trade or literally anything else.
That's not a value judgement or a judgement of people's intelligence or lack thereof (unlike a lot of techies, I don't believe we're smarter than anyone else) or a belief that you can't acquire or develop skills - it's just fact.
I'm a Software Developer, but I don't see why everyone should have to, or feel like they have to, learn to code.
In general, kids and adults alike, but especially kids, should spend more time being active, around others (within reason, these are extraordinary times), and outside - not in front of computer screens.
Not everyone is cut out for or interested in coding, just like not everyone is cut out for or interested in medicine, law, a trade or literally anything else.
That's not a value judgement or a judgement of people's intelligence or lack thereof (unlike a lot of techies, I don't believe we're smarter than anyone else) or a belief that you can't acquire or develop skills - it's just fact.
I think there's a reason this is such a recurrent theme that keeps coming up in different forms across the decades. Often people who are not developers have sensible ideas for apps/websites but do not have access to engineers who can implement them. This is especially true in enterprises.
For example the content team in a company like Doordash won't have access to engineers to help automate content creation.
But people in that team WILL have ideas around how they can automate their processes using a low-code/no-code tool.
Shameless plug - I am myself making one of these tools to help more folks DIY tools, flows & apps without making it themselves. We're here at https://getmason.io
For example the content team in a company like Doordash won't have access to engineers to help automate content creation.
But people in that team WILL have ideas around how they can automate their processes using a low-code/no-code tool.
Shameless plug - I am myself making one of these tools to help more folks DIY tools, flows & apps without making it themselves. We're here at https://getmason.io
As a programmer, I've got a love for code but I have to accept that this is going to be the future for 90% of consumer-facing apps. The most common abstractions for the most common use-cases are already built and they're going to stay that way in my opinion. Once the "hard thinking" work is done building these abstractions, it's just a matter of connecting the dots to bring a product to market in <insert industry of choice>. While there's been no-code tools for a long time (Yahoo pipes being my earliest memory) there's no doubt they're improving every day.
I think in a few years (decades?), "developer" and "programmer" will mean something very different that they do today.
I think in a few years (decades?), "developer" and "programmer" will mean something very different that they do today.
I'm a programmer who does a lot of "no code" development and find those tools very productive for many of the problems I deal with. And I observe every day the people who know "programming" can use those tools far more effectively and come up with far better solutions and solve far harder problems than the people who cannot program, but just learned the tool.
The hard part of programming is computational thinking, and coming up with novel ways to string the right algorithms together to get the result the client needs, not typing vs dragging and dropping.
The hard part of programming is computational thinking, and coming up with novel ways to string the right algorithms together to get the result the client needs, not typing vs dragging and dropping.
""" I think in a few years (decades?), "developer" and "programmer" will mean something very different that they do today."""
Hello. Your opinion is very interesting. And can you tell your version of this in more detail.
Very old idea. First one I remember was COBOL--enables accountants to learn to use computers "without having to program", meaning without having to learn 1401 code.
Later, there was the 5th generation movement with Prolog or Prolog-type langauges.
Before that there was Fourth Generation Programming.
Building systems is hard and requires programming. So people look for a way around it, leading to the next generation of "no-code". Then, the systems reach some sort of inflection point where programming is again required to add functionality.
[Edit] See also "No Silver Bullet" for a thoughtful discussion about complexity of problems. This cycle will continue to repeat.
Later, there was the 5th generation movement with Prolog or Prolog-type langauges.
Before that there was Fourth Generation Programming.
Building systems is hard and requires programming. So people look for a way around it, leading to the next generation of "no-code". Then, the systems reach some sort of inflection point where programming is again required to add functionality.
[Edit] See also "No Silver Bullet" for a thoughtful discussion about complexity of problems. This cycle will continue to repeat.
the shift already happened -- the shift is that software ate all the CRUD business processes that could possibly exist
if you want to build something cool now it had better do more than update a database
if you want to build something cool now it had better do more than update a database
I mostly agree, but I suspect not all CRUD businesses have been eaten. The ones that have been eaten have the following property:
-- You have to enter the information in yourself, or your equipment currently captures it for you
There are still CRUD opportunities where you find, capture and enter the information on behalf of the user. The phone captures a lot of data, so all that is already CRUDed up, but if you had novel data -- say from a wearable device -- you could still produce a new CRUD for that.
I think this is why hardware is hot again. It allows us to automatically capture new data that isn't already captured by the phone.
-- You have to enter the information in yourself, or your equipment currently captures it for you
There are still CRUD opportunities where you find, capture and enter the information on behalf of the user. The phone captures a lot of data, so all that is already CRUDed up, but if you had novel data -- say from a wearable device -- you could still produce a new CRUD for that.
I think this is why hardware is hot again. It allows us to automatically capture new data that isn't already captured by the phone.
Laugh all you want, but I genuinely believed that XML standards, yes those 'design by committee' standards like XForms, XProc, XPath/XQuery 3.0+ and just general web standards like XHTML 2.0 could've been the future and a backbone of something that a lot of people could use and not just as customers.
Not by writing XML by hand without proper tools, but using something built upon this, on an extensible, inter-operated web. Think using modern XMPP for messaging, instead of a zoo of messaging apps that can't talk to each other or Yahoo Pipes on steroids. But that's not the universe we live in and that's not the no-code we're talking about.
Not by writing XML by hand without proper tools, but using something built upon this, on an extensible, inter-operated web. Think using modern XMPP for messaging, instead of a zoo of messaging apps that can't talk to each other or Yahoo Pipes on steroids. But that's not the universe we live in and that's not the no-code we're talking about.
What is the best way to represent and manipulate an abstract syntax tree, or maybe a directed graph of flow control and data movement?
Text is just there as a crutch to language-brain. Image brain is fast with concepts, but bad at details.
Text is just there as a crutch to language-brain. Image brain is fast with concepts, but bad at details.
I've tried this with my current company, where the majority is not tech savy. The business analysts had immense difficulty in creating and maintaining automations on their own. And it gets worse: the few devs that we have at the company had to "rescue" the no-code automations on a daily basis and ended up rewriting most of them. It takes longer for a dev to create an automation in a no-code platform than by simply writing code for this solution.
Your mileage may vary, but my feeling is that no-code will keep growing in relevance, but it's not there yet on what it claims to do.
Your mileage may vary, but my feeling is that no-code will keep growing in relevance, but it's not there yet on what it claims to do.
I think it stems from the inability to realize that it's not the fact that programming is currently done by typing words and symbols into text files that makes it hard for some people.
But that it requires some ability to break up a problem into simpler tasks and then solving those tasks using discrete actions.
The people who can program in no-code environments can also program in all other environments.
Sure, there are _LOTS_ of ways to improve the status quo, and any idea should be tried, but I'd much rather explore more interactive programming environments than focus on the input method.
The people who can program in no-code environments can also program in all other environments.
Sure, there are _LOTS_ of ways to improve the status quo, and any idea should be tried, but I'd much rather explore more interactive programming environments than focus on the input method.
Explaining the power of programming to someone who can’t code is like explaining living in 3 dimensions to a someone in a 2D universe.
If you can’t code, nocode seems awesome. If you can, it seems like 2D in a 3D world.
If you can’t code, nocode seems awesome. If you can, it seems like 2D in a 3D world.
It relates to a lot of things. One thing like telephone adoption "at this rate, everyone will need to be an operator" and then we had self-dial phones instead of switchboard operators. So for simple often done things people can do it themselves. For other rare/special things we can still call for an operator (we still have those right?)
Another way to look at it is like computer architecture. We have technologies for holding data and impedance mismatches between them, so we make intermediary caches, integrated/hybrid devices and devices start blending to look like each other 3D XPoint/NVMe. On another scale a Facebook datacentre can look like a macroscale computer architecture. My point is that 'programming' and programmers started out being one thing, but there will be many different forms of this at many levels, in various vertical areas. We already have specialized platform (Shopify) programmers, and self-serve (Zapier/Airtable) and even among those there could be third-party helpers as has happened around Google sheets data collectors/analyzers. Lo-code/no-code is so many things. It comes back to 'any sufficiently capable configuration schema becomes a lisp'. People want to tweak, so they learn to program.
Another way to look at it is like computer architecture. We have technologies for holding data and impedance mismatches between them, so we make intermediary caches, integrated/hybrid devices and devices start blending to look like each other 3D XPoint/NVMe. On another scale a Facebook datacentre can look like a macroscale computer architecture. My point is that 'programming' and programmers started out being one thing, but there will be many different forms of this at many levels, in various vertical areas. We already have specialized platform (Shopify) programmers, and self-serve (Zapier/Airtable) and even among those there could be third-party helpers as has happened around Google sheets data collectors/analyzers. Lo-code/no-code is so many things. It comes back to 'any sufficiently capable configuration schema becomes a lisp'. People want to tweak, so they learn to program.
> (we still have those right?)
I think there might still be operators to help setting up a call with a deaf person. Other than that, I had kind of assumed that the concept was obsolete. What would you need an operator for?
I think there might still be operators to help setting up a call with a deaf person. Other than that, I had kind of assumed that the concept was obsolete. What would you need an operator for?
Software engineering is too hard. A relatively easy project still needs a coder that has had lots of training and then the never ending maintenance comes after. Even the no code version takes lots of work.
We need the ikea version of software development where a lay person can put together a common type of app and maintenance is mostly automatic. I think the nocode "movement" is here to stay and it's only going to get bigger, in terms of number of apps, and ease of use.
We need the ikea version of software development where a lay person can put together a common type of app and maintenance is mostly automatic. I think the nocode "movement" is here to stay and it's only going to get bigger, in terms of number of apps, and ease of use.
I do think it's a major shift but not in a mutually exclusive way, and maybe not a "paradigm" shift. I think initially, no-code tools were touted as being for non-developers. But now there is a realization that no-code tools are more like "automation" for completing a task. In that mindset, anyone (developer or not) can benefit from using them since it can be/should be/is more efficient. To the extent that no-code tools let a non-developer build and test an end-to-end app as their business, I think that's rare today but I would say we're on our way towards it.
I liken the no-code movement to the introduction of a higher-level programming language. For certain tasks, the higher-level language is more than adequate and a developer (or user) who knows nothing about OSes, file systems or networking, can build an application and probably create value and make money. But the higher-level language doesn't replace the lower-level language overnight, and for certain tasks it'll never replace it.
To use the example you mentioned, if you just want to display a webpage for your co-workers that lets them filter a SQL table, it might take you a few minutes to build that in Retool. If there is a class of such webpages or webapps that could make you money, then it's easy to see Retool as a new higher-level language for building those types of apps.
So, my view is that it's not a paradigm shift for building software, but rather the next step on an evolution towards a more automated process of building software.
Disclosure: I founded a no-code web testing app https://reflect.run
I liken the no-code movement to the introduction of a higher-level programming language. For certain tasks, the higher-level language is more than adequate and a developer (or user) who knows nothing about OSes, file systems or networking, can build an application and probably create value and make money. But the higher-level language doesn't replace the lower-level language overnight, and for certain tasks it'll never replace it.
To use the example you mentioned, if you just want to display a webpage for your co-workers that lets them filter a SQL table, it might take you a few minutes to build that in Retool. If there is a class of such webpages or webapps that could make you money, then it's easy to see Retool as a new higher-level language for building those types of apps.
So, my view is that it's not a paradigm shift for building software, but rather the next step on an evolution towards a more automated process of building software.
Disclosure: I founded a no-code web testing app https://reflect.run
[deleted]
I wrote this on another thread a few months ago:
I think the basic reason why low-code / no-code works is down to software bugs and long-tail maintenance.
Bugs are a function of number of engineers, features, moving parts, and significant lines of code.
No-code takes out engineers, moving parts, and SLoC from the equation (as far as the enterprises buying these solutions are concerned), but leaves a lot to be desired in terms of feature set; low-code brings down number of engineers, and SLoC, whilst providing flexibility in terms of bespoke feature sets.
Also, in essence, No-code and Low-code are a natural extension of the cloud computing model in which capex is traded away for opex. And economies of scale, over time ensures Low-code / No-code will be cheaper yet more reliable than anything one (tech-enabled) enterprise can roll on their own. While at some level it is also an indication of 'software is eating the world' phenomena (both in terms of available capital given software economics, and rise in popularity of CS, in general).
https://news.ycombinator.com/item?id=27074657
I think the basic reason why low-code / no-code works is down to software bugs and long-tail maintenance.
Bugs are a function of number of engineers, features, moving parts, and significant lines of code.
No-code takes out engineers, moving parts, and SLoC from the equation (as far as the enterprises buying these solutions are concerned), but leaves a lot to be desired in terms of feature set; low-code brings down number of engineers, and SLoC, whilst providing flexibility in terms of bespoke feature sets.
Also, in essence, No-code and Low-code are a natural extension of the cloud computing model in which capex is traded away for opex. And economies of scale, over time ensures Low-code / No-code will be cheaper yet more reliable than anything one (tech-enabled) enterprise can roll on their own. While at some level it is also an indication of 'software is eating the world' phenomena (both in terms of available capital given software economics, and rise in popularity of CS, in general).
https://news.ycombinator.com/item?id=27074657
I see a lot of great tools these days that describe themselves as no-code. To me it kind of means: this tool is a tad more powerful than average and can accomplish things you might expect to need code for. In that sense, handing every user tools that are a little bit more powerful, seems great.
The "no-code" where you are building end user apps inside a proprietary, cloud based WYSIWIG editor, that seems like a fad.
The "no-code" where you are building end user apps inside a proprietary, cloud based WYSIWIG editor, that seems like a fad.
It's another case of "your profession will be automated and replaced", which has always historically proven to be both true and false.
The "professions" that get replaced typically aren't professions by the time they can be reliably automated, in that they are usually monotonous tasks that don't contribute to the advancement of any field.
Everything evolves, but the bulk of people creating new software are still coding it after decades, just the same as the bulk of musicians creating new music are still playing instruments after centuries and millennia.
Perhaps our coding tools will eventually become so advanced we can just think it and a piece of software will be created, but that's also boring and unchallenging and will likely have the equivalent creative value of singing into a voice-changing social media filter. We have this in the present day but people still write and perform songs that others perceive as valuable.
The goalposts of what constitutes "creating" reliably move just as much as people continue to need to get their hands dirty in order to craft actual innovation.
The "no-code movement" is perhaps more an example of a "no-movement" trying to masquerade as a movement.
I don't mean to deride it, some things can and should be automated, and this is valuable in itself as it shifts the goals of innovation along. But it's misleading to elevate such things higher than their pay-grade.
And sure, maybe sometime AI and deep-learning could anticipate and create everything we need - "the singularity", etc - but at such a point, that innovation itself has been automated, we'll all probably just happily hang out at the beach, as there'd be no more work left to be done anyway.
The "professions" that get replaced typically aren't professions by the time they can be reliably automated, in that they are usually monotonous tasks that don't contribute to the advancement of any field.
Everything evolves, but the bulk of people creating new software are still coding it after decades, just the same as the bulk of musicians creating new music are still playing instruments after centuries and millennia.
Perhaps our coding tools will eventually become so advanced we can just think it and a piece of software will be created, but that's also boring and unchallenging and will likely have the equivalent creative value of singing into a voice-changing social media filter. We have this in the present day but people still write and perform songs that others perceive as valuable.
The goalposts of what constitutes "creating" reliably move just as much as people continue to need to get their hands dirty in order to craft actual innovation.
The "no-code movement" is perhaps more an example of a "no-movement" trying to masquerade as a movement.
I don't mean to deride it, some things can and should be automated, and this is valuable in itself as it shifts the goals of innovation along. But it's misleading to elevate such things higher than their pay-grade.
And sure, maybe sometime AI and deep-learning could anticipate and create everything we need - "the singularity", etc - but at such a point, that innovation itself has been automated, we'll all probably just happily hang out at the beach, as there'd be no more work left to be done anyway.
There’s nothing new, here. It’s been going on for decades, in one form or another.
Visual Basic was sort of a “no code” solution, at one time (of course, it is, actually, “code,” but the barest minimum possible).
The dream of the C-Suite has always been to toss out those filthy engineers, and generate product directly from the (obviously) superior minds of the executives.
Not sure how well that’s worked out, so far…
Visual Basic was sort of a “no code” solution, at one time (of course, it is, actually, “code,” but the barest minimum possible).
The dream of the C-Suite has always been to toss out those filthy engineers, and generate product directly from the (obviously) superior minds of the executives.
Not sure how well that’s worked out, so far…
The thing is, I hear people give as examples "excel", "visualbasic", and all I can think of is "wow, these are wildly successful technologies that improved the lives of millions of people"
Also, these types of technologies do not reduce demand for real programmers. And a desire to deploy them - effectively to make a product more "programmable" by end users - may not be rooted in a desire to replace developers, but rather to make the product more useful, and thus be able to charge a higher premium for it.
Also, these types of technologies do not reduce demand for real programmers. And a desire to deploy them - effectively to make a product more "programmable" by end users - may not be rooted in a desire to replace developers, but rather to make the product more useful, and thus be able to charge a higher premium for it.
I know a guy that had the best thing ever happen to his career, because of this.
Back in the last century, he was a well-paid employee of a bank (C++). He managed a group of experienced engineers.
The bank wanted to roll out a new product, and they asked him to submit a bid from his group. He specced out a reasonable 18-month plan for a C++ project.
A Vice-President then stepped in, and yanked the project, stating that he, and a small team of sycophants, could do the project in six months, using VB.
My friend quit, and spent the next two years, traveling the world.
When he came back, the project was a shambles, the VP had been fired, and the bank was begging my friend to come back.
He vowed never to be an employee again, and signed on as a contractor, for an eye-watering rate; which the bank immediately paid.
Last I talked to him, he’d brought a house in a Tony neighborhood, for cash, and he wasn’t even 40, yet.
Back in the last century, he was a well-paid employee of a bank (C++). He managed a group of experienced engineers.
The bank wanted to roll out a new product, and they asked him to submit a bid from his group. He specced out a reasonable 18-month plan for a C++ project.
A Vice-President then stepped in, and yanked the project, stating that he, and a small team of sycophants, could do the project in six months, using VB.
My friend quit, and spent the next two years, traveling the world.
When he came back, the project was a shambles, the VP had been fired, and the bank was begging my friend to come back.
He vowed never to be an employee again, and signed on as a contractor, for an eye-watering rate; which the bank immediately paid.
Last I talked to him, he’d brought a house in a Tony neighborhood, for cash, and he wasn’t even 40, yet.
That's a great story! And it makes a lot of sense - you are getting people used to thinking about automation, demanding automation, and trying to deploy automation to more places than before. You are also creating all sorts of APIs exposed by documents and making things more scriptable.
That's going to increase demand for developers of all languages, even if some of that demand consists of hiring professionals when people recognize they are in over their head with one of these scripting languages, or that they've stretched their existing tools and it's time for a more powerful tool.
The downside is horror stories of developers being called in to fix a tangled mess of VB macros. But there's also gold to be mined in those hills.
That's going to increase demand for developers of all languages, even if some of that demand consists of hiring professionals when people recognize they are in over their head with one of these scripting languages, or that they've stretched their existing tools and it's time for a more powerful tool.
The downside is horror stories of developers being called in to fix a tangled mess of VB macros. But there's also gold to be mined in those hills.
I wrote ~300 lines of Python in a day and then I passed it to an Okta dev who has spent the last three months trying to replicate it in Okta‘s no code platform with limited success.
At first I was interested in the tool, but seeing how long it’s taken him and his struggles to get things working has convinced me that he probably would have been better served to just learn Python.
At first I was interested in the tool, but seeing how long it’s taken him and his struggles to get things working has convinced me that he probably would have been better served to just learn Python.
Not a bad thing, but you should understand the economic ramifications of it.
"No code" is basically commodification. For some subset of IT tasks, there are now tools you can use to achieve your goals without employing a software engineer. Great - it makes everybody more productive when humans can be replaced by software.
But note that commodity markets, by definition, are low-profit. If you can use some cheap off-the-shelf tool to achieve a goal, so can all your competitors. So people thinking they're going to build the next great billion-dollar web startup off of Wix or Shopify are probably going to be disappointed. They can build a great web startup, but so can everybody else. You can no longer make life-changing sums of money just by being able to throw together a website.
It's more useful to businesses whose competitive advantage is elsewhere. If you make complicated hardware, for example, and just want to be able to sell it without paying the Amazon tax, these tools are great.
"No code" is basically commodification. For some subset of IT tasks, there are now tools you can use to achieve your goals without employing a software engineer. Great - it makes everybody more productive when humans can be replaced by software.
But note that commodity markets, by definition, are low-profit. If you can use some cheap off-the-shelf tool to achieve a goal, so can all your competitors. So people thinking they're going to build the next great billion-dollar web startup off of Wix or Shopify are probably going to be disappointed. They can build a great web startup, but so can everybody else. You can no longer make life-changing sums of money just by being able to throw together a website.
It's more useful to businesses whose competitive advantage is elsewhere. If you make complicated hardware, for example, and just want to be able to sell it without paying the Amazon tax, these tools are great.
It seems like the period when this idea hit its peak was in the late 1980s and early 1990s. That's when there were a lot of apps built to maximize what non-programmers could do, and which also offered the easiest possible on-ramp for people who did want to write simple scripts. Among the big successes of that time:
Hypercard
Macromedia Director, which later evolved into Flash
VisualBasic, which had fantastic WYSIWYG tools for interfaces
A little later:
Dreamweaver
PageMill
All the early Web tools (there were hundreds)
It is difficult to now remember the cult that existed around Hypercard for awhile, and which lead to spin off products, like SuperCard.
There was a real mania at that time to make it easy for everyone to learn the basics of programming.
At some point after 2000, and especially after 2010, the idea seemed to fade, and the tech industry for awhile got caught up in going in a very different direction: big frameworks, increasingly complex, increasingly abstract, a development system that required more and more tools.
I would like to see some of the old "education for the masses" energy come back.
Hypercard
Macromedia Director, which later evolved into Flash
VisualBasic, which had fantastic WYSIWYG tools for interfaces
A little later:
Dreamweaver
PageMill
All the early Web tools (there were hundreds)
It is difficult to now remember the cult that existed around Hypercard for awhile, and which lead to spin off products, like SuperCard.
There was a real mania at that time to make it easy for everyone to learn the basics of programming.
At some point after 2000, and especially after 2010, the idea seemed to fade, and the tech industry for awhile got caught up in going in a very different direction: big frameworks, increasingly complex, increasingly abstract, a development system that required more and more tools.
I would like to see some of the old "education for the masses" energy come back.
What's fascinating to me as that it's happening at the same time as the "X as code" movement.
Devops: Infrastructure as code. or dbt's viewpoint on analytics as code (see https://blog.getdbt.com/building-a-mature-analytics-workflow...)
So I'm seeing it as an exercise in finding sweet spots. There are things that have been mostly manual or point-and-click and people are seeing wins from defining and managing them as code. Usually in terms of reproducibility and testability. Then there are things that people have traditionally done in code (e.g. admin UIs) where maybe most of it can be abstracted away into a point and click tool.
No-code works great until it breaks, and then your ability to debug is going to be very constrained. We're fighting that problem with some no-code ETLs using Stitch at work today, for example.
Devops: Infrastructure as code. or dbt's viewpoint on analytics as code (see https://blog.getdbt.com/building-a-mature-analytics-workflow...)
So I'm seeing it as an exercise in finding sweet spots. There are things that have been mostly manual or point-and-click and people are seeing wins from defining and managing them as code. Usually in terms of reproducibility and testability. Then there are things that people have traditionally done in code (e.g. admin UIs) where maybe most of it can be abstracted away into a point and click tool.
No-code works great until it breaks, and then your ability to debug is going to be very constrained. We're fighting that problem with some no-code ETLs using Stitch at work today, for example.
It’s awful and I wish the fad would go away. Just please stop.
I work at a fortune 100 company where a team just had to write off over 2 years of development at over $10M. Executives were sold a no-code solution and then instructed their team to use it for some complex business processes (duh). It was obvious to a few of us but wow, what a shame.
I work at a fortune 100 company where a team just had to write off over 2 years of development at over $10M. Executives were sold a no-code solution and then instructed their team to use it for some complex business processes (duh). It was obvious to a few of us but wow, what a shame.
Doesn't work. And I've had practical experience using low-code platforms, "selling" them and even built a couple myself.
First - there's no complete solution. notice how they all have a "custom code" feature for you to fill in what's missing using JS or proprietery language. And you need a developer for that. These platform only work so long as you stick exactly to the use-case they had in mind.
Second - Business/non-dev users don't have the skills nor the inclination to use these platforms. It may look simple, just drag'n'drop, connect the dots, But what if it fails? why did it fail? when will it fail? they don't have the experience and mindset to debug and account for edge cases, and they don't even want to learn how to do it! no matter how easy the no-code platform is.
These conclusions I payed for in blood, sweat and money.
First - there's no complete solution. notice how they all have a "custom code" feature for you to fill in what's missing using JS or proprietery language. And you need a developer for that. These platform only work so long as you stick exactly to the use-case they had in mind.
Second - Business/non-dev users don't have the skills nor the inclination to use these platforms. It may look simple, just drag'n'drop, connect the dots, But what if it fails? why did it fail? when will it fail? they don't have the experience and mindset to debug and account for edge cases, and they don't even want to learn how to do it! no matter how easy the no-code platform is.
These conclusions I payed for in blood, sweat and money.
In my experience, these tools are sometimes a fantastic option for developers to alleviate some of the burden of managing infrastructure and code. But I've rarely seen a powerful solution which can be used by non-developers; either because the tool is powerful, but complex, and thus the same skillset it takes to be a developer ends up being necessary to interface with the tool, or because the tool is integrating with systems/APIs developers wrote, and it takes a developer to understand how to handle that interface.
But I think they're really cool none-the-less, as a developer. I can build a modern react web application with the best of them, but I still pay for a squarespace personal site. At work, we use a ton of zapier and retool; when the problem space fits, its just less dev work. But the devs are the ones who do maintain it, at the end of the day.
But I think they're really cool none-the-less, as a developer. I can build a modern react web application with the best of them, but I still pay for a squarespace personal site. At work, we use a ton of zapier and retool; when the problem space fits, its just less dev work. But the devs are the ones who do maintain it, at the end of the day.
It's been there for a while now with wix, wordpress (divi, elementor), etc. It does solve some problems, for the right people.
I don't think it's a movement that will gain popularity more than it is right now, most people who use it for a while will realise its limit and either hire a software dev or jump into coding.
I don't think it's a movement that will gain popularity more than it is right now, most people who use it for a while will realise its limit and either hire a software dev or jump into coding.
Seems okay to me, it's just one more layer of abstraction higher up the chain.
The organizational problem is controlling ad hoc app proliferation by non development units and thereby creating unsupported shadow systems. So, when used by dev teams I see no problem, but usage by operational units should be highly policed.
The organizational problem is controlling ad hoc app proliferation by non development units and thereby creating unsupported shadow systems. So, when used by dev teams I see no problem, but usage by operational units should be highly policed.
Seems okay to me, it's just one more layer of abstraction higher up the chain.
Exactly.
C++ is no-code if you work in x86 assembler.
Exactly.
C++ is no-code if you work in x86 assembler.
I mean, once upon a time, UI design and digital composing were "coded". Slowly things get hoisted out of deeply technical domains, or at least, such that someone talented at other things can apply their type of technical knowledge. An artist generally makes a better UI designer than a programmer.
What I don't like is the trend of teaching people to almost reach their goals, without also teaching them how to fill in the details that the "Do What I Say" tool cannot.
What would be a more laudable and practical goal would be something that eases people into more advanced programming, or points them down different paths that are associated. It is useful to know "No, I don't want to do this, but
So in the end, I think the "No code" movement is just the latest iteration of sky high dreams. It looks like training wheels, but it is anything but.
What I don't like is the trend of teaching people to almost reach their goals, without also teaching them how to fill in the details that the "Do What I Say" tool cannot.
What would be a more laudable and practical goal would be something that eases people into more advanced programming, or points them down different paths that are associated. It is useful to know "No, I don't want to do this, but
So in the end, I think the "No code" movement is just the latest iteration of sky high dreams. It looks like training wheels, but it is anything but.
God I'd love it so much if 'idea people' could use some sort of no-code tool to get their idea 80% of the way there, so I can start cracking on the remaining 20%, or even not at all.
This would really clear me up for valuable work instead of having to rehash the same quick fixes for broken data modeling paterns.
This would really clear me up for valuable work instead of having to rehash the same quick fixes for broken data modeling paterns.
Any attempt to drastically reduce the difficulty of programming has one of two effects: either it fails miserably, or it works brilliantly and immediately raises the bar of what is expected out of our software. "No code" should be understood in the same vein as COBOL was supposed to eliminate the need for highly trained programmers (per a sibling comment). Obviously COBOL didn't do that, so the question is whether this is a hype bubble or a new incremental step.
Personally, my money is on hype. All the demos I've seen are pretty impressive, but very shallow. Large apps are complicated beasts, and scaling usually ruins simplistic demos pretty quickly. Furthermore they seem to suffer from the same issue that prevented COBOL for making programmers obsolete: defining requirements correctly is very, very hard.
Personally, my money is on hype. All the demos I've seen are pretty impressive, but very shallow. Large apps are complicated beasts, and scaling usually ruins simplistic demos pretty quickly. Furthermore they seem to suffer from the same issue that prevented COBOL for making programmers obsolete: defining requirements correctly is very, very hard.
I think coding and no-coding should eventually converge.
Software development has become far too complex without the right sensible abstractions keeping things under control.
Every developer would probably want an Airtable control to drop into their app, that they can use to build up their schema and then add custom functionality. But there isn’t one. I think mostly because there were too many technologies coming along at such a rapid pace that integrating became difficult because everyone is using a different tech stack and changing tech stacks all the time. And there are new libraries to do everything. E.g. No one uses Redux anymore. Graphql came along. Everyone is back on SQL. And what’s next?
The pace of tech needs to settle down and then we can build some solid reusable libraries that do the same thing as no code tools.
Software development has become far too complex without the right sensible abstractions keeping things under control.
Every developer would probably want an Airtable control to drop into their app, that they can use to build up their schema and then add custom functionality. But there isn’t one. I think mostly because there were too many technologies coming along at such a rapid pace that integrating became difficult because everyone is using a different tech stack and changing tech stacks all the time. And there are new libraries to do everything. E.g. No one uses Redux anymore. Graphql came along. Everyone is back on SQL. And what’s next?
The pace of tech needs to settle down and then we can build some solid reusable libraries that do the same thing as no code tools.
I don't like it because it is marketing scam term.
In reality there is so much no-code/low-code solutions already there in place. Whole Wordpress ecosystem with plugins - you basically can do webshop in couple clicks, if you are writing webshop from scratch then you are stupid.
Then there are pointy haired bosses who think they can substitute their developers with low code. That is also stupid because their company probably needs developers. Like if they are SaaS provider - they ARE low code for other businesses and replacing developers with some low code will make company to be simply reseller of someone else business.
If you are SaaS vendor - you are low code provider for other businesses and from what I see many managers don't understand it and think they can make money on someone else solution.
In reality there is so much no-code/low-code solutions already there in place. Whole Wordpress ecosystem with plugins - you basically can do webshop in couple clicks, if you are writing webshop from scratch then you are stupid.
Then there are pointy haired bosses who think they can substitute their developers with low code. That is also stupid because their company probably needs developers. Like if they are SaaS provider - they ARE low code for other businesses and replacing developers with some low code will make company to be simply reseller of someone else business.
If you are SaaS vendor - you are low code provider for other businesses and from what I see many managers don't understand it and think they can make money on someone else solution.
I have experience with low and no code tools since the 80s and built a bunch myself (for niches like insurance) and eat my own dogfood by using my own no code tools for current (side and client) projects.
What I found is what everyone finds; when the tool does not support something, it gets very hard.
I think of that as follows: the request to make that 'impossible' feature came from somewhere; if you rethink the feature so it's trivial to click together with the tool and then convince the owner of the feature to accept that reality, you often get away with it. Just accepting that you don't need certain complexity for things to function well is often, imho, a perfectly fine solution.
If the client or owner does not accept to work this way, I don't use no/low code at all.
What I found is what everyone finds; when the tool does not support something, it gets very hard.
I think of that as follows: the request to make that 'impossible' feature came from somewhere; if you rethink the feature so it's trivial to click together with the tool and then convince the owner of the feature to accept that reality, you often get away with it. Just accepting that you don't need certain complexity for things to function well is often, imho, a perfectly fine solution.
If the client or owner does not accept to work this way, I don't use no/low code at all.
The concept of "no code" has been in existence for much longer than the term "no code" has been in use. For example Excel spreadsheets have existed longer than the term "no code" and these allow people from a non software background to automate some of their tasks, but even now we don't tend to call this "no code". There's very specific connotations with the term, which is why I think at the moment "no code" is typically used as a marketing and sales play. This is something I wrote about in more depth here: https://www.lesinskis.com/whats-the-deal-with-no-code.html
The most popular programming environment on the planet is Microsoft Excel, a no-code product.
I think a lot of developers are very anti-no-code because they know, as any rational person does, that any no-code solution flexible enough to do everything will look pretty much just like programming. But no-code shouldn't be a 'do everything' solution, it should be a 'do a lot of things more easily' solution. No-code, to me, means tools designed to bridge the gap between non-programmers and programmers and allow individuals to access computing at levels that are comfortable for them while on-ramping them towards more and more programming as their needs increase. This is what personal computing is all about.
I think a lot of developers are very anti-no-code because they know, as any rational person does, that any no-code solution flexible enough to do everything will look pretty much just like programming. But no-code shouldn't be a 'do everything' solution, it should be a 'do a lot of things more easily' solution. No-code, to me, means tools designed to bridge the gap between non-programmers and programmers and allow individuals to access computing at levels that are comfortable for them while on-ramping them towards more and more programming as their needs increase. This is what personal computing is all about.
Formulas are the code, otherwise FORTRAN is another popular no-code product.
[deleted]
By that logic, typing a URL into a browser or an email address into the "To:" field is code.
They're not wrong, but they don't solve anything hard either, so they'll find that there's little value to extract from no code tooling.
They live in a difficult bracket to find offering customers in: medium+ projects have most of their complexity in making the business domain model and understanding it's intricacies, well before you attempt to make a computer understand them; no code tooling only cover the latter. Small- projects live comfortably in Excel sheets, as scary as that sound for the reading cohort, it appears evident that a lot of the no code market is already captured by that, and they're not offering anything to challenge the dominant player in the space.
They live in a difficult bracket to find offering customers in: medium+ projects have most of their complexity in making the business domain model and understanding it's intricacies, well before you attempt to make a computer understand them; no code tooling only cover the latter. Small- projects live comfortably in Excel sheets, as scary as that sound for the reading cohort, it appears evident that a lot of the no code market is already captured by that, and they're not offering anything to challenge the dominant player in the space.
Isn't this what software development is all about?
We make tech more accessible for people who can't code and then we move to the next thing.
I saw a bunch of freelancers fail, because they had the impression they could sell people basic homepages as a job for their whole life...
We make tech more accessible for people who can't code and then we move to the next thing.
I saw a bunch of freelancers fail, because they had the impression they could sell people basic homepages as a job for their whole life...
What do I think about no-code?
"Data" Driven Development (DDD), if you need a buzzword/acronym, is where I think about code and data in the same bucket (ie. Lisp). I can check a box to enabled something, type some text in a field to provide the i8n label and database field. Easy. Underneath somewhere, there's obviously still code, more complex code, to make all of this work.
Or, what do I think of the so-called "movement?"
As a single independent developer, I am in a bubble. I can't predict the future. I'd like to see powerful rapid development tools out there, but more and more I see a lot of locked up proprietary walled fortresses disguised as movements.
"Data" Driven Development (DDD), if you need a buzzword/acronym, is where I think about code and data in the same bucket (ie. Lisp). I can check a box to enabled something, type some text in a field to provide the i8n label and database field. Easy. Underneath somewhere, there's obviously still code, more complex code, to make all of this work.
Or, what do I think of the so-called "movement?"
As a single independent developer, I am in a bubble. I can't predict the future. I'd like to see powerful rapid development tools out there, but more and more I see a lot of locked up proprietary walled fortresses disguised as movements.
I've been pitched on no-code data solutions in healthcare for over a decade, and it never seems to work out. At least in that space, people confuse who their main audience is: I don't want to use a no-code solution because I can code, and most of my stakeholders won't use a no-code solution because it wasn't code that was their barrier (it was time, specialization, analytic skills-- that's why they hire me). So I just watch vendors pitch me on how much easier my life would be if I could drag and drop analytic pipelines (lol, no.), or I watch them pitch doctors on how they can train their own machine learning models.
There's no such thing as no code, just someone else's code.
Also, website generators have always existed since the web is the web.
The main problem with website generators is vendor lock-in. If the vendor goes away so does your website. If the vendor unilaterally changes their price structure, you have no leverage. If the vendor comes with any new arbitrary terms of service, you have no leverage either.
If the vendor decides to block your website due to some false positive from an automated system, you may have no recourse and your entire web presence is gone while the problem is resolved, if it ever gets resolved. Meanwhile you have no way to deploy your stuff anywhere else.
Also, website generators have always existed since the web is the web.
The main problem with website generators is vendor lock-in. If the vendor goes away so does your website. If the vendor unilaterally changes their price structure, you have no leverage. If the vendor comes with any new arbitrary terms of service, you have no leverage either.
If the vendor decides to block your website due to some false positive from an automated system, you may have no recourse and your entire web presence is gone while the problem is resolved, if it ever gets resolved. Meanwhile you have no way to deploy your stuff anywhere else.
Assembly -> ... -> Ruby -> Rails -> -> UIs to deal with framework abstractions
I think the 'no code' is just a marketing term to explain something that everyone here is familiar with: the tradeoffs of building with abstractions.
On the one hand, powerful abstractions to build-a-blog-in-15-mins. On the other, the decrease in flex/extensibility and the maintenance pains that come with using tools in unintended ways.
We'll get to a stage where we can build with VR-think-about-a-component-and-see-it-appear or w/e but we all know there's always inherent complexity that eventually requires going under the hood or just straight up reimplementing.
I think the 'no code' is just a marketing term to explain something that everyone here is familiar with: the tradeoffs of building with abstractions.
On the one hand, powerful abstractions to build-a-blog-in-15-mins. On the other, the decrease in flex/extensibility and the maintenance pains that come with using tools in unintended ways.
We'll get to a stage where we can build with VR-think-about-a-component-and-see-it-appear or w/e but we all know there's always inherent complexity that eventually requires going under the hood or just straight up reimplementing.
I ran a no-code startup about 10 years ago for building mobile apps. My experience has been that no-code is empowering... until it isn't. There's always a piece of bespoke functionality where suddenly the environment you're in becomes a trap unless there's a plugin ecosystem that enables you to write your own integrations. Oftentimes building these plugin customizations becomes more difficult than if you'd built the whole thing in-scratch yourself.
Video of the tool i built: https://www.youtube.com/watch?v=V6_NJ8zcm8o
Video of the tool i built: https://www.youtube.com/watch?v=V6_NJ8zcm8o
Without going into the actual reality of current products... and current marketing claims...
All technology has natural adoption phases. The technical problem becomes better understood. The technical solution is improved. The market problem and solution become better understood and improved, and presented in terms that make sense from a user perspective, and solve their problem. It becomes easier to use, More people adopt it.
Typically runs through several different companies' lifetimes; some would argue the changes are so great, it requires different companies, with different foci and competences, at different phases.
All technology has natural adoption phases. The technical problem becomes better understood. The technical solution is improved. The market problem and solution become better understood and improved, and presented in terms that make sense from a user perspective, and solve their problem. It becomes easier to use, More people adopt it.
Typically runs through several different companies' lifetimes; some would argue the changes are so great, it requires different companies, with different foci and competences, at different phases.
I think most no-code solutions fail to think about what happens when a software engineer turns out to be needed after all.
It makes it easy for really simple websites/apps to be built, but the reality is that business people have no idea of how complex something can be and after they started using no-code tools they hit a hard wall of having to rebuild everything with a real software developer.
In reality though it would be nice if there's a solid hand-off between no-code and the "properly build and tested" world.
That said, they can be good for prototyping or brochure apps/websites that just serve information and have some forms.
It makes it easy for really simple websites/apps to be built, but the reality is that business people have no idea of how complex something can be and after they started using no-code tools they hit a hard wall of having to rebuild everything with a real software developer.
In reality though it would be nice if there's a solid hand-off between no-code and the "properly build and tested" world.
That said, they can be good for prototyping or brochure apps/websites that just serve information and have some forms.
> Is this a paradigm shift?
Graphical "low-code" programming has been around for a long time in e.g. the control systems community, where people typically have strong math am physics backgrounds (e.g., knowledge of vehicle dynamics), but little experience with programming or software engineering.
Matlab Simulink and LabVIEW are well-known products that offer a low code approach to these fields. Large and complex projects are done with these tools.
IMO the complexity is shifted from interacting with the hardware to wrestling with the tools, e.g. version control, knowing what happens exactly and cooperation is really hard.
Graphical "low-code" programming has been around for a long time in e.g. the control systems community, where people typically have strong math am physics backgrounds (e.g., knowledge of vehicle dynamics), but little experience with programming or software engineering.
Matlab Simulink and LabVIEW are well-known products that offer a low code approach to these fields. Large and complex projects are done with these tools.
IMO the complexity is shifted from interacting with the hardware to wrestling with the tools, e.g. version control, knowing what happens exactly and cooperation is really hard.
I would like to hear more from people wrestling with labVIEW projects of sufficient complexity. My (albeit decade-ago) experience is they lack the communities and subtoolings and things break at a point of complexity, thus the "wrestling with the tools" that could help clean things up gets harder when using a no-code flow-based environment.
Actually part of the LHC collider is programmed in LabView.
https://www.apexwaves.com/blog/using-nis-pxi-hardware-to-con...
https://www.apexwaves.com/blog/using-nis-pxi-hardware-to-con...
It’s not new but an old idea which is a bit of a fad. People will try to take it too far and then realize it’s not good for everything but the idea rightfully should get some increased mindshare.
Code, especially these days, can get quite insanely complicated and pretty far from being a concise description of appearance and behavior. Fiddling with frameworks and libraries and language features instead of doing the thing you’re actually trying to do has gotten to be too much and no-code fad is the response.
It should also be an implicit call for “hey lets try to reduce complexity” but that is rarely listened for.
Code, especially these days, can get quite insanely complicated and pretty far from being a concise description of appearance and behavior. Fiddling with frameworks and libraries and language features instead of doing the thing you’re actually trying to do has gotten to be too much and no-code fad is the response.
It should also be an implicit call for “hey lets try to reduce complexity” but that is rarely listened for.
Business value and technical implementation details method are not necessarily connected in any way…something that in my opinion many engineers should think about more often.
You can make a lot of money on sophisticated custom technology, or you can make a lot of money with very little technology or even white-labeling someone else’s technology.
Every business should focus on the basic value proposition on for their business and product and make decisions that support it.
How do we make money, and where is the best place for our time to be invested to make more money? That’s it, that’s the only question there is.
You can make a lot of money on sophisticated custom technology, or you can make a lot of money with very little technology or even white-labeling someone else’s technology.
Every business should focus on the basic value proposition on for their business and product and make decisions that support it.
How do we make money, and where is the best place for our time to be invested to make more money? That’s it, that’s the only question there is.
No-code it's just code, but scattered around in many forms and places, instead of being a bunch of text files in a folder.
At the end of the day you are still instructing a machine to operate.
Every task that's complex enough still requires a "coder mentality" to perform.
It's just that many people don't want to bother with the quirks of classic programming languages and the technical baggage that they drag around from birth.
The worst feeling comes when you realize you are spending most of the time fighting with the tools than actually solving the problem you had in the first place.
At the end of the day you are still instructing a machine to operate.
Every task that's complex enough still requires a "coder mentality" to perform.
It's just that many people don't want to bother with the quirks of classic programming languages and the technical baggage that they drag around from birth.
The worst feeling comes when you realize you are spending most of the time fighting with the tools than actually solving the problem you had in the first place.
What is 'no code'? Is it everything you can do with computer without writing code? That would probably be too much. Maybe it is about adding a feature (to an existing system) without any code that seems like previously you had to write code for adding it.
The definition is tricky when you start from a negative.
There is a companion term 'low code' - because people discovered that 'no code' is too restrictive. But that is even more foggy. If a new library comes out and suddenly your program shrinks to a short script - is that 'low code'?
The definition is tricky when you start from a negative.
There is a companion term 'low code' - because people discovered that 'no code' is too restrictive. But that is even more foggy. If a new library comes out and suddenly your program shrinks to a short script - is that 'low code'?
I echo a lot of comments here that low-code/no-code isn't a recent movement. I think the one exciting trend that I've noticed among the historical instances of this like Lotus Notes, Microsoft Access, SharePoint Sites, etc is that they are very exciting to business users and hence gain massive adoption, which eventually turns into universal revulsion by IT at having to maintain these massive numbers of specialized apps and makes for a very difficult transition.
Seems potentially lucrative if you can build a successful business around one.
Seems potentially lucrative if you can build a successful business around one.
I’ve had a few of times over my 16 year software development career (mostly early on) where I’ve seen tools that have made me pause and think “that’s it, this is going to make my job obsolete”
None of them ever have, of course. It turns out it’s really difficult to make and maintain general purpose tools that allow for non-engineers to generate the end result they want. If for no other reason this is because of the edge cases. You can get really far, but for the most part I’d describe the limits as capable of a really good proof-of-concept.
None of them ever have, of course. It turns out it’s really difficult to make and maintain general purpose tools that allow for non-engineers to generate the end result they want. If for no other reason this is because of the edge cases. You can get really far, but for the most part I’d describe the limits as capable of a really good proof-of-concept.
No-code is really a pushback against the over-code or code-abuse in today's layers upon layers of tech mess.
Old RAD tools like VisualBasic is far superior than no-code. GUI is better than CLI if done right.
Old RAD tools like VisualBasic is far superior than no-code. GUI is better than CLI if done right.
I like a lot of what’s out there these days. Pega is a good example that reasonably talented people with some training can solve real business problems quickly. But like most other folks here mention it’s usually great to remember the guard rails that help make these tools easy for some will be limiting to others. Maybe one day the Linux kernel devs will be using a drag and drop interface..but I think that day is probably a long way away (not speaking for the Linux kernel devs here obviously just my take)
If you've been doing web dev from the go, you surely remember Front Page and Dreamweaver. Both built the code from the Adobe Photoshop layers. Completely no-code (perhaps b/c gathering user data from web forms was not done just yet, the web was uni-directional publishing).
Eventhough we had these tools I still preferred to code from scratch, simply I could not stand the output code, it was messy, full of unused stuff, excesively commented, etc.
I like to look under the hood and understand what's going on. This is not for me.
Eventhough we had these tools I still preferred to code from scratch, simply I could not stand the output code, it was messy, full of unused stuff, excesively commented, etc.
I like to look under the hood and understand what's going on. This is not for me.
To give an analogy to natural language, a lot of no-code users want to skip past learning the rules of Latin and jump straight in to writing a 1000 page treatise in Latin.
The problem with no-code is it generally appeals to a class of non-programmers who think programming is hard because of syntax. They don’t understand that coding is hard because it’s about understanding and solving hard problems that touch human computer interaction, legal/compliance and computer science domains (among others).
The problem with no-code is it generally appeals to a class of non-programmers who think programming is hard because of syntax. They don’t understand that coding is hard because it’s about understanding and solving hard problems that touch human computer interaction, legal/compliance and computer science domains (among others).
The whole "no-code" thing is mostly yet another marketing stunt that tries to establish a fake paradigm. WYSIWYG have existed since the beginning of home computing. By all standards, Dreamweaver or Frontpage are also "no code" and I'm quite sure they are more than 20 year old.
It's not a "movement" it's a boring marketing campaign about some tools that are nothing new.
Let's call these tools "shit code generators" instead and try market that.
It's not a "movement" it's a boring marketing campaign about some tools that are nothing new.
Let's call these tools "shit code generators" instead and try market that.
It's okay, but by its very nature, it's not as flexible as code. Often I see an argument describing low-code tools as "Pareto efficient", but even that turns out to be a false economy once your use case becomes a little more complex.
Generally speaking, if you're doing something beyond building a simple form or table, and have some serious business logic to implement, in my experience, code is the only way to go. Anything else feels somewhat sub-optimal.
Generally speaking, if you're doing something beyond building a simple form or table, and have some serious business logic to implement, in my experience, code is the only way to go. Anything else feels somewhat sub-optimal.
Yeah I felt that way too until I saw a demo from my current employer lido, https://www.lido.app/. We break the no code gordian knot by using spreadsheet formulas as business logic.
I've been writing code for 40 years and doubt that no-code will generally take over any time soon. In my field I've seen environments like LabView take over certain niches but also painfully aware of their shortcomings.
On the flip side, my wife and I ran a home bakery for a while and I LOVED the website builder we used. Click, click, click - full integration with credit card processing, email handling, etc. No way I'd sit there at night hand building a website.
On the flip side, my wife and I ran a home bakery for a while and I LOVED the website builder we used. Click, click, click - full integration with credit card processing, email handling, etc. No way I'd sit there at night hand building a website.
The most miserable software experience I've had was trying to support a Microsoft BI system built with a no-code tool. It was all drag-and-drop and fill in the boxes. Instead of code you were left with an inscrutable XML file. It was nearly impossible to trace the flow from input to output, and even worse if you were trying to go backwards from output to input. Good luck to you if someone had a question about how a value in the database was derived.
I have been interested to see what one can do in Smartsheets. However, I have also ended up debugging the workflows set up by a co-worker--not particularly technical. I guess that I would say that the Smartsheets workflows reduce the need for coding, but not for considering possible states and transitions.
And the creators of Smartsheets seem to have heard and run with somebody's maxim that "It doesn't matter what users say they want, they want Excel."
And the creators of Smartsheets seem to have heard and run with somebody's maxim that "It doesn't matter what users say they want, they want Excel."
If the code can't be ported to other environments or it's not open source than it's "not-code". These are tools to get specific tasks done and I don't think they're replaceing code. They're replacing other less compatible tools.
It's funny that in all this thread there is no mention of MS Access. One of the best no code tools there is, and you can find millions of application in many industries based on Access.
It's funny that in all this thread there is no mention of MS Access. One of the best no code tools there is, and you can find millions of application in many industries based on Access.
I think this particular paradigm shift happens every 15 to 20 years :)
Even in the event of a perfect “no code” era, i.e. a future where we speak to the computer and tell it what we want it to do, we’d still have programmers. They just would be doing the job very differently. Maybe we wouldn’t even call them programmers at that point. But the job would be there.
Complexity will never go away and you’ll always need someone to manage it. That’s life, that’s reality.
Even in the event of a perfect “no code” era, i.e. a future where we speak to the computer and tell it what we want it to do, we’d still have programmers. They just would be doing the job very differently. Maybe we wouldn’t even call them programmers at that point. But the job would be there.
Complexity will never go away and you’ll always need someone to manage it. That’s life, that’s reality.
As has been pointed out already, this is yet another round of an old paradigm. Just like every other shortcut (looking at you, frameworks) it comes down to LEGOs (or Minecraft). As long as you are satisfied with blocks world, they are great. As soon as you need a curved surface or a different color, you are out of luck. There's also that detail that someone has to write all that code so you don't have to.
I propose the following statements:
1. Reducing complexity by reducing capability/power is easy. 2. Moving complexity from one form to another is easy.
The biggest issue is that these limitations are not well understood by the end users of these products. Inevitably, they want something that the product didn't account for and have to grapple either with the complexity inherent in doing it or come to terms with not being able to do it.
1. Reducing complexity by reducing capability/power is easy. 2. Moving complexity from one form to another is easy.
The biggest issue is that these limitations are not well understood by the end users of these products. Inevitably, they want something that the product didn't account for and have to grapple either with the complexity inherent in doing it or come to terms with not being able to do it.
I've used Microsoft's tools, like the Power platform and Logic Apps. For anything interesting you want to do it boils down to Excel-like functions. Have you ever worked with a series of nested If statements in Excel? Its kind of a nightmare to think about and there is definitely code there.
If you want to do something really really basic its fine. If you want to do something complicated then its a hinderance.
If you want to do something really really basic its fine. If you want to do something complicated then its a hinderance.
Shameless plug to https://hal9.com -- We believe there is a place for no-code, as long as you are not prevented from exporting or changing the components with code. We enable data analysis with parametrizable blocks which are 100% backed by open-source code, we believe you get the best of both worlds with hybrid solutions like this one.
While no-code tools have existed forever, the difference is now they have finally found their niche – workflow automation for mid to large sized companies.
I have personally seen entire departments move from pen and paper to off-the-shelf boxed software to SaaS and now to no-code apps. You can finally customize your software exactly how you like without hiring a team of developers, and that's a great thing.
I have personally seen entire departments move from pen and paper to off-the-shelf boxed software to SaaS and now to no-code apps. You can finally customize your software exactly how you like without hiring a team of developers, and that's a great thing.
Which no-code apps have this ability? the ones I know are rather basic
This comes up when engineers are expensive, and goes away when they are cheap. It's hard to build a competitive edge when your app is identical to everyone elses and you can't make any fundamental changes due to the framework you're using.
Now that being said, there are a ton of "apps" that really shouldn't need to be coded if you aren't making a competitive go of things.
Now that being said, there are a ton of "apps" that really shouldn't need to be coded if you aren't making a competitive go of things.
It depends a lot. If you think of Wix/Shopify as 'no code' they are extremely powerful tools.
Lower than that, it becomes complicated as we don't have an easy way of abstracting front/back end, the business logic is still business logic.
Some things to help designers do higher level stuff, like layout, but still work below that level of abstraction is a bonus, but this is surprisingly very hard.
Lower than that, it becomes complicated as we don't have an easy way of abstracting front/back end, the business logic is still business logic.
Some things to help designers do higher level stuff, like layout, but still work below that level of abstraction is a bonus, but this is surprisingly very hard.
I’m still waiting for widespread adoption of 4GL or 5GL from the 1970s/1980s. I’m all for no-code but the problem is after a while you outgrow the platform then you need low code. You know what low code is? It’s code. The moment you have code, you have all the associated “code problems?
Personally I’ve spent more time working on domain specific languages than I have trying to eliminate code.
Personally I’ve spent more time working on domain specific languages than I have trying to eliminate code.
It will probably solve simple problems as it will enable "no-coders" to actually do things really without any code with AI-assisted-visual-drag-and-drop "coding". But that doesn't seem like to take off for any serious work soon. It might be a gateway for beginners to perform some simple tasks and to start actual programming by diving in though.
There is still code in no code in the same way that there is still procedural code running when I execute an SQL query. I don't care how much code is being executed. I care about maintenance burden. Postgres is better maintained than anything I can make. So I'd rather just maintain the SQL query than the entire procedural mass that's actually executed.
It's vastly better than previous iterations on the same idea. Some (e.g. Airtable) are much better than others, perhaps because they have a clearer niche. Others are useful but drive you straight into a swamp called Technical Debt (retool). I don't think they represent a paradigm shift, more an iterative improvement on existing tools.
I don't think they're going to allow non-developers to do much because you have to grasp the concepts of software development to use them effectively.
With that in mind, for quick/dirty things they're great. I've thrown together proofs of concept in NodeRed in 45 minutes that would otherwise take hours / days of boilerplate.
With that in mind, for quick/dirty things they're great. I've thrown together proofs of concept in NodeRed in 45 minutes that would otherwise take hours / days of boilerplate.
Code is simply a way we formalize requirements to the specificity required for a computer to fulfill and honor them. So a developer's job is to make vague requirements more specific via the coding process. Find another way of moving to an equivalent representation of every detail captured in code, and call it anything you like.
People who cannot code get excited about technology trends and then have a fantasy that they can participate without working hard. It's called "no-code".
There's tons of advanced software tools on computers that do amazing things without code. We don't call it "no-code", we just call it using a computer.
There's tons of advanced software tools on computers that do amazing things without code. We don't call it "no-code", we just call it using a computer.
The best no code tools empower non-developers (and are thus poorly understood by HN). You’ve named some good examples.
In my B2B saas company we massively increased customer satisfaction by making it easy to integrate with retool and metabase and then letting anyone internal or external extend the product with new views and functionality.
In my B2B saas company we massively increased customer satisfaction by making it easy to integrate with retool and metabase and then letting anyone internal or external extend the product with new views and functionality.
I think that nocode could be very useful for many small companies. Yet it's very hard to build a truly scalable nocode service. You would need to be able to easily expand it with full-code components and all components must be able to interact with each other freely. UI must be accessible for ordinary people.
Hard task. But doable.
Hard task. But doable.
This is such an old concept that it's been beaten into the ground at this point. These "movements" aren't really movements, they're product bandwagons. Notice how most of these "no-code" solutions are proprietary, for-profit, non-standard and unwilling to be anything but.
https://writer.zohopublic.com/writer/published/kiaow0e244617...
Just wrote this piece putting down my thoughts on what I call domain driven no-code platforms.
Just wrote this piece putting down my thoughts on what I call domain driven no-code platforms.
Nocode has its place, and the problem area it can reasonably address will grow over time, but at the end of the day good automation requires the same thing any other software system requires: complex logic and, therefore, tests.
Code is going to be the most efficient way to express and verify that logic.
Code is going to be the most efficient way to express and verify that logic.
I know an agency of 5 people absolutely flat out delivering low-code solutions on the MS Power Platform, mostly for government agencies.
The thing is, these solutions probably couldn't be delivered by non-engineers, but these people are able to move extremely quick because of the platform.
The thing is, these solutions probably couldn't be delivered by non-engineers, but these people are able to move extremely quick because of the platform.
Counter example: MS Flow. It is a nice idea but is completely torpedoed by Microsoft itself. All workflows are executed in a user context and if you want that to change you have to pay thousands of dollars and self-host infrastructure. HTTP is a "premium" feature... Some function don't work with MS own features to block networks by IP. they release their Azure IP range tables, but it still doesn't work. The usability is worse than 2010 SharePoint workflows with the exception that it can interface a range of web services by predefined adapters.
Power Apps is quite buggy and quite difficult to implement with questionable design decisions (The programming language changes with regional language, so member selectors like . get translated to ,) that makes code incompatible if you change Power Apps language (yes, really). Not that you can easily export/import projects from one tenent to another. The programming language itself is not less complicated than classic languages, the strength is the platform. What wordpress is to blogs, Power Apps wants to be for mobile apps if you will.
Power BI is a lightweight App that basically leverage pivot functions of Excel is a small web app. Quite useful, but there should be no illusions about the capabilities. Nice for quick data analysis with the usual drill down.
For a government to use Power Apps means to be extremely dependent on MS. It is rather questionable and very expensive in my opinion.
That said, no code workflows and applications builders would help a lot. But current examples are severely lacking in my opinion.
Power Apps is quite buggy and quite difficult to implement with questionable design decisions (The programming language changes with regional language, so member selectors like . get translated to ,) that makes code incompatible if you change Power Apps language (yes, really). Not that you can easily export/import projects from one tenent to another. The programming language itself is not less complicated than classic languages, the strength is the platform. What wordpress is to blogs, Power Apps wants to be for mobile apps if you will.
Power BI is a lightweight App that basically leverage pivot functions of Excel is a small web app. Quite useful, but there should be no illusions about the capabilities. Nice for quick data analysis with the usual drill down.
For a government to use Power Apps means to be extremely dependent on MS. It is rather questionable and very expensive in my opinion.
That said, no code workflows and applications builders would help a lot. But current examples are severely lacking in my opinion.
Most apps with the power platform are indeed LoB applications which people here would immediately cry over for bad UX/UI. If you do not care about that (big orgs often seem to not), many many old and new low/no code tools can do the job.
[deleted]
I think it's great to see the commoditization of solved problems.
On the other hand, I'm not surprised to see developers hating on the idea because our industry has spent decades telling everybody these are difficult problems and they need to hire experts to help solve them.
On the other hand, I'm not surprised to see developers hating on the idea because our industry has spent decades telling everybody these are difficult problems and they need to hire experts to help solve them.
I had to fix a SharePoint workflow that indefinitely kicked off several workflows, and each workflow kicked off other workflows all being stuck in loops. A single workflow could have thousands of workflows kicking off...
Guess who they let make something that simple? Some generic business analyst who left and nobody else knew how to support it.
That second last word there is why developers will never go away.
Guess who they let make something that simple? Some generic business analyst who left and nobody else knew how to support it.
That second last word there is why developers will never go away.
Sure, but there's some kind of survivorship bias there.
For every "app" like that, which grows up and needs support, there are dozens of others that serve out their usefulness and go away, or just live on in obscurity in some person's personal workflow.
And generic business analysts are hardly the only ones who write bad code...
For every "app" like that, which grows up and needs support, there are dozens of others that serve out their usefulness and go away, or just live on in obscurity in some person's personal workflow.
And generic business analysts are hardly the only ones who write bad code...
That's because business analysts don't get to touch code because they don't know what they're doing. You give every generic Business Degree holder access to visual studio and make custom apps and suddenly 5-10 years down the road companies will be relying on a sole piece of terribly optimized, unsafe, and security prone software that hackers globally will have a wet dream over.
This isn't just an "Oh developers trying to retain their jobs" rhetoric. This is a "keep power tools away from children" concept. Not saying Comp Sci degrees are terribly hard to acquire, just that there is a reason those people went in and got a Business degree and not a hard science degree. It's typically because they wanted the easy way out.
This isn't just an "Oh developers trying to retain their jobs" rhetoric. This is a "keep power tools away from children" concept. Not saying Comp Sci degrees are terribly hard to acquire, just that there is a reason those people went in and got a Business degree and not a hard science degree. It's typically because they wanted the easy way out.
> Is this a paradigm shift?
No. IIRC, companies have been hyping stuff like this for literally 40 years: https://en.wikipedia.org/wiki/The_Last_One_(software)
No. IIRC, companies have been hyping stuff like this for literally 40 years: https://en.wikipedia.org/wiki/The_Last_One_(software)
It's still coding, just more high-level. I think it misguides energy a bit. Just make regular programming more high-level, but don't try to hide all code and loose direct access to it.
Then again for some applications it works great: website designers, simple chatbots etc.
Then again for some applications it works great: website designers, simple chatbots etc.
In case you don't know, early compilers were developed under the hype term "automatic programming".
COBOL was designed to be used by business people.
Whether it is connecting wires, punching cards, typing in an IDE, connecting code blocks, or making flowcharts - it is all programming.
COBOL was designed to be used by business people.
Whether it is connecting wires, punching cards, typing in an IDE, connecting code blocks, or making flowcharts - it is all programming.
My hot take: No Code, from a non dev perspective, is just a really user hostile config interface.
Ideal no-code solution would be that can talk to users, convert user stories to code, debug/fix code that broke production server and can make sense of new/existing technologies. Anything other than that is just abstraction over already existing code.
I'm still not sure what difference is between 'no-code' and just using software. If I create a workflow in Jira I wouldn't say I'm creating no-code software, I'd describe that as just 'using' or 'managing' Jira.
Some areas of software are well-suited to solutions which require no coding. Photoshop is a great example. PowerPoint and Word are another. WordPress is another. Some of these are enhanced with code (WordPress, Excel).
Over time all software areas will have no-code options.
Over time all software areas will have no-code options.
I think there’s “good” no code and “bad.”
Bad is where there’s only no code and it’s impossible to drill down. Or use outside of a walled garden.
Good is when the end product is portable and can be worked on outside the tool.
I think the problem comes when noncoders hit a wall and can’t go any further.
Bad is where there’s only no code and it’s impossible to drill down. Or use outside of a walled garden.
Good is when the end product is portable and can be worked on outside the tool.
I think the problem comes when noncoders hit a wall and can’t go any further.
I think the most famous no-code app is WordPress.
Some estimate that 70% of all websites run WordPress. But I can tell you my salary was paid by customers who wanted this 'one custom application' that was not available as WordPress plugin.
Some estimate that 70% of all websites run WordPress. But I can tell you my salary was paid by customers who wanted this 'one custom application' that was not available as WordPress plugin.
I think they will need a whole lot of coders to get things going and hiding its ugly bowels swelling up.
I'm building and maintaining 'self-service' BI apps every day since about 2011. It's profitable. So, the more, the better.
I'm building and maintaining 'self-service' BI apps every day since about 2011. It's profitable. So, the more, the better.
I think people want "no-code" solutions because they're intimidated by code. I think they're intimidated by code because they're intimidated by programming culture. If a large number of people outside of programming are intimidated by programming culture then it is by definition intimidating.
If programming was instead seen to be a welcoming, warm, and supportive culture, I don't think no-code would have very much persuasive power. The effectiveness of no-code as a brand should cause more people in programming to pause and consider the fact that the value proposition is not having to deal with programmers. People literally sell products on the basis of not having to interact with our community. That should cause us great concern about the health of our community and should trigger introspection.
If programming was instead seen to be a welcoming, warm, and supportive culture, I don't think no-code would have very much persuasive power. The effectiveness of no-code as a brand should cause more people in programming to pause and consider the fact that the value proposition is not having to deal with programmers. People literally sell products on the basis of not having to interact with our community. That should cause us great concern about the health of our community and should trigger introspection.
It is mostly just repurposing older stuff in my opinion to make it sound cooler and make it the new fad. You know what the biggest no code tool is ? WordPress. Tell me why it is different than the shiny new no code tools.
no-code works and has been working for a long time now, depending on how you define it. Think of all the web site builders, young and old, and all the things they helped non technical people achieve. The difference now is that the tech is better and more mature - standard, scalable APIs at lower cost, so no-code tools are getting better, and this new wave will IMO impact how companies operate and create internal tools.
Will someone create the next letter in FAANG with bubble or retool? I don't think so, but will those tools help many people in several industries? I believe so.
I tweeted this ([link redacted]):
The thing with no-code is that there is still code. Only now it doesn't live in git but in a magic ether between sites and services, and in the head of that ex-employee who set it up two years ago.
The thing with no-code is that there is still code. Only now it doesn't live in git but in a magic ether between sites and services, and in the head of that ex-employee who set it up two years ago.
I've been pretty unimpressed with the results to be honest. There has been a lot of hype around businesses that have little value-add and lots of great marketing.
I love the concept -- quickly spin up an MVP, etc -- but when so much of success lies on execution and so many good ideas need time to be perfected before they commercially viable spinning up things very quickly isn't always the best.
I love the concept -- quickly spin up an MVP, etc -- but when so much of success lies on execution and so many good ideas need time to be perfected before they commercially viable spinning up things very quickly isn't always the best.
I want the No-Code Movement to succeed--creating tools that both developers and non-developers can use.
But I think that almost every marketing claim from a No-Code company or those dudes selling $500 No-Code courses is false.
But I think that almost every marketing claim from a No-Code company or those dudes selling $500 No-Code courses is false.
I find that it is great until you want to do something it doesn't really support... and then it is hell. The inflexibility is a killer. I am only interested in a system that lets you code if you want.
No-code is definitely useful today for certain specific use cases, especially to create apps that collect data, store it in a database, and report to the client the results of some analysis of that data.
It's just buzzword bingo. Complexity doesn't go away, it just moves around. Thinking about user interaction, product lifecycle, collaboration, knowledge pools etc. doesn't tie in to 'code' as a one-to-one, and if you swap out code for something else those still exist.
The problem isn't code, the problem is the ability to analyse the problem, formulate requirements and design a solution. How you express that is an implementation detail at best. This is also where the problem with the marketing of those tools lies: it pretends that when you don't write code, you also don't have to do those other things.
Ultimately this is just the same balance you get everywhere else. You have operating systems, tools, interfaces, frameworks, languages etc. that all do various things. Depending on what things you need to do and how novel they are you might be able to use and re-use existing systems, and you'll be adding to the same generic pool of applications that already exist. This is where automation-of-automation shines, depending on the level of genericness.
Regarding problem solving, again, not code-related, you can solve problems in a conversation, on paper, using calculations etc. Yet any anti-code product is marketed as being able to avoid those, but that is not how problem solving works.
Now, if we bring this all together a bit I find a question popping up: is this whole thing actually solving problems that exist? It's very easy to see a 'problem' if you're working in a bad workflow. But the 'problem' that is seen then often isn't the actual problem, but just a symptom. So now we are not solving a problem but 'solving' a symptom. This happens whenever someone is set to 'fix' something but doesn't actually know how to find the problem and then find the solution.
Long-winded Example:
Joe and Bob work at different companies. They need to exchange a bunch of rows of information and they do this by exporting a database table from some web app to a CSV file and emailing that.
Joe (Source) uses some Database GUI with an 'export' button, grabs the file, puts it in an email as an attachment and sends it to Bob.
Bob (Destination) receives the email, downloads the attachment, goes to his Database GUI, uses an 'import' button, points it to the file he just downloaded and now his task is complete.
Joe and Bob won't want to constantly drag and drop CSV files, so they come up with a plan to use LowCodeNoCode Creator Studio XP Edition to automatically export the CSV, email it to a predefined email address, process the email, download the CSV, and import the CSV. From their perspective, they solved the problem! Without writing code!
From a problem's perspective: the symptom is now hidden and the problem is made worse because nobody knows how this process works, why it exists, who did what, and how to manually intervene. On top of that, the real problem still isn't solved. Even the argument that "there is no code so anyone can find out how it works" doesn't hold up because while you don't need to learn some syntax you swap that problem out with learning some tool.
The real problem is Master-Slave table replication, and if we analyse it one level deeper: messing about with a database table that is owned by an application. If you want to interact with data that is owned by an application you don't go messing about with the underlying persistence store, you use the application and if needed write an API extension that does the job. Heck, that API probably already exists in any modern application! But then you'd actually have to know how systems work, how to resolve requirements and how to come up with documentation and scoping and the foresight of future endeavours.
The problem isn't code, the problem is the ability to analyse the problem, formulate requirements and design a solution. How you express that is an implementation detail at best. This is also where the problem with the marketing of those tools lies: it pretends that when you don't write code, you also don't have to do those other things.
Ultimately this is just the same balance you get everywhere else. You have operating systems, tools, interfaces, frameworks, languages etc. that all do various things. Depending on what things you need to do and how novel they are you might be able to use and re-use existing systems, and you'll be adding to the same generic pool of applications that already exist. This is where automation-of-automation shines, depending on the level of genericness.
Regarding problem solving, again, not code-related, you can solve problems in a conversation, on paper, using calculations etc. Yet any anti-code product is marketed as being able to avoid those, but that is not how problem solving works.
Now, if we bring this all together a bit I find a question popping up: is this whole thing actually solving problems that exist? It's very easy to see a 'problem' if you're working in a bad workflow. But the 'problem' that is seen then often isn't the actual problem, but just a symptom. So now we are not solving a problem but 'solving' a symptom. This happens whenever someone is set to 'fix' something but doesn't actually know how to find the problem and then find the solution.
Long-winded Example:
Joe and Bob work at different companies. They need to exchange a bunch of rows of information and they do this by exporting a database table from some web app to a CSV file and emailing that.
Joe (Source) uses some Database GUI with an 'export' button, grabs the file, puts it in an email as an attachment and sends it to Bob.
Bob (Destination) receives the email, downloads the attachment, goes to his Database GUI, uses an 'import' button, points it to the file he just downloaded and now his task is complete.
Joe and Bob won't want to constantly drag and drop CSV files, so they come up with a plan to use LowCodeNoCode Creator Studio XP Edition to automatically export the CSV, email it to a predefined email address, process the email, download the CSV, and import the CSV. From their perspective, they solved the problem! Without writing code!
From a problem's perspective: the symptom is now hidden and the problem is made worse because nobody knows how this process works, why it exists, who did what, and how to manually intervene. On top of that, the real problem still isn't solved. Even the argument that "there is no code so anyone can find out how it works" doesn't hold up because while you don't need to learn some syntax you swap that problem out with learning some tool.
The real problem is Master-Slave table replication, and if we analyse it one level deeper: messing about with a database table that is owned by an application. If you want to interact with data that is owned by an application you don't go messing about with the underlying persistence store, you use the application and if needed write an API extension that does the job. Heck, that API probably already exists in any modern application! But then you'd actually have to know how systems work, how to resolve requirements and how to come up with documentation and scoping and the foresight of future endeavours.
Exactly. The code isn't the hard part. The hard part is abstract thinking and logic.
I created an email escalation notification system that was manipulated with graphics in a flow diagram. My users couldn't handle the precise logic for doing the escalation chain and always asked for help. Turns out, _that's_ what I'm good at. Logic and abstract reasoning.
I created an email escalation notification system that was manipulated with graphics in a flow diagram. My users couldn't handle the precise logic for doing the escalation chain and always asked for help. Turns out, _that's_ what I'm good at. Logic and abstract reasoning.
I see the same thing in most ticketing and planning systems, they all have some logic to decide what next steps are allowed and to edit those steps you modify a graphical representation of a state machine.
You don't need to write code to modify it, but if you have no knowledge of flows or state machines or logical succession of events you simply can't solve the problem. It's not hard, but no-code isn't going to make it less hard either.
You don't need to write code to modify it, but if you have no knowledge of flows or state machines or logical succession of events you simply can't solve the problem. It's not hard, but no-code isn't going to make it less hard either.
Advocates of which are:
- corporate climbers
- CV driven development engineers
- those who don't know how to code - those who know they are bad at it
- technically curious non engineers
No code feels to me like an ORM like django. Conceptually easier but theres a ton of stuff done in the background that as soon as you want anything special you end up in a world of hurt.
Except in Django it doesn’t hurt, because the ability to send straight SQL to the DB is built in.
No code is fine. It’s not much different from front end development where developers cannot figure out how to dynamically put text on a page without 300mb of framework and dependencies.
Web development was much closer to no-code at Macromedia Dreamweaver 8. Then came Adobe.
The machinery behind web sites outside of the top 100 ought to be standardized by now.
The machinery behind web sites outside of the top 100 ought to be standardized by now.
Code is the OG 'No Code'. Or to give the movement its full title 'No Machine Code'.
I wonder if programmers of the day thought that compilers would put them out of a job?
I wonder if programmers of the day thought that compilers would put them out of a job?
If there is a truly great product that can make this work well for simple reports and simple CRUD apps, I would love it.
I personally would like to be working on more interesting projects.
I personally would like to be working on more interesting projects.
Imagine if this were the case in other field. A "no words" movement for people that want to publish a book but don't want to bother with the writing part.
I invite you to take a look at the world of AI writers that are currently flooding the market.
I've seen massive sites with hundreds of thousands of crappy ai articles getting a LOT of traffic.
I've seen massive sites with hundreds of thousands of crappy ai articles getting a LOT of traffic.
No code has the potential to be a Visual Basic for the enterprise for tasks that are cookie cutter. However the adoption cost is very high for tools like Appian.
I don't see it as fundamentally different than the promise of products like MS Access. It empowers users to do stuff but I'm not losing sleep.
I suppose I should view it as a threat to my living. But nah. I think we'll have enough sloppy legacy systems for my lifetime left over.
every so many years this movement comes back and has a different name. I think I've now seen 5 iterations of it over the last 25 years. back when frontpage was first launched everyone screamed it would be the end of web development and everyone and your mom would build websites and we wouldn't need those cranky developers anymore. and here we are.
At the end of the day you need to express your logic in some form. I don’t think it matters too much because modelling data is hard.
Are compilers in general a part of the no-code movement since we don't have to write extensive asm now? Same as it ever was.
Lotus Notes was the earliest true nocode tool.
I was using it in 1990 to build nocode distributed replicated GUI form and view driven applications.
I was using it in 1990 to build nocode distributed replicated GUI form and view driven applications.
Frontpage, dreamweaver, joomla, wordpress, etc.
"No-code" and "Low-code" - it's all still code, just someone else's that you don't control.
recycled trend, nothing is new here. "the cloud" started as no code if you still remember. At some point, clicking around a web console frustrated us so much we created tools like ansible, terraform, cloud formation etc. I would not take this mob seriously before they start taking about the code review and testing workflow.
The new “ford assembly line” for us at commit.dev is:
1) Do it manually. 2) Scale with no-code. 3) Optimize and protect with custom software.
1) Do it manually. 2) Scale with no-code. 3) Optimize and protect with custom software.
Everything about no-code screams vendor lockin. It's stupid and I'd never use or recommend these things.
There are many open-source no-code tools so you can gain full control over your data/application with them as well as contribute into the source code.
For instance, you can deploy an admin panel with https://www.getmotoradmin.com/ (plug) and save a lot of time on building custom internal tools.
For instance, you can deploy an admin panel with https://www.getmotoradmin.com/ (plug) and save a lot of time on building custom internal tools.
No code just means non text based code with limitations, perfect for people that are scared of text.
I just added a no-code to our product instead of a scripting language. So far, users really like it.
Been there, done that, wasn't long before I wanted back more powerful syntax tools.
A lot of comments here point to users eventually running up against the boundaries of no/low-code environments and having to make the decision to graduate from them or push their limits to a place where they were really not intended to be used.
I've spent the past 1.5 years or so building a no-code data analytics tool called Mito [1] -- a spreadsheet extension to JupyterLab that lets previously Excel-based workers make the switch to a Python based environment. Unlike other no/low-code data analytics tools we spend a large amount of engineering time making sure that users are never locked into Mito. We do this in 2 ways: Firstly, every time you make an edit to your data in the Mito spreadsheet, we automatically generate the equivalent Python code for you. And secondly, to make it easy to work with that code, Mito is an extension to your JupyterLab environment. By existing in the IDE that you would otherwise be using if you didn't have the low-code environment, its really easy for users to switch back and forth between working in the Mito no-code environment and writing code themselves.
Practically, what we've seen over the past year is that giving users ownership of the code that they create using Mito and existing in JupyterLab has been incredibly important. The most active Mito users are those that use Mito in conjunction with custom Python code that they or their company has written. They do things like incorporate API calls to access their data, use advanced pandas/Python functionality that we don't support, etc.
TLDR: We believe that no/low-code are most powerful when they are augments to the "real deal" code-first workflow instead of a substitution.
[1] https://trymito.io/hn
I've spent the past 1.5 years or so building a no-code data analytics tool called Mito [1] -- a spreadsheet extension to JupyterLab that lets previously Excel-based workers make the switch to a Python based environment. Unlike other no/low-code data analytics tools we spend a large amount of engineering time making sure that users are never locked into Mito. We do this in 2 ways: Firstly, every time you make an edit to your data in the Mito spreadsheet, we automatically generate the equivalent Python code for you. And secondly, to make it easy to work with that code, Mito is an extension to your JupyterLab environment. By existing in the IDE that you would otherwise be using if you didn't have the low-code environment, its really easy for users to switch back and forth between working in the Mito no-code environment and writing code themselves.
Practically, what we've seen over the past year is that giving users ownership of the code that they create using Mito and existing in JupyterLab has been incredibly important. The most active Mito users are those that use Mito in conjunction with custom Python code that they or their company has written. They do things like incorporate API calls to access their data, use advanced pandas/Python functionality that we don't support, etc.
TLDR: We believe that no/low-code are most powerful when they are augments to the "real deal" code-first workflow instead of a substitution.
[1] https://trymito.io/hn
[deleted]
when it comes to no code, this is the best out there
https://github.com/kelseyhightower/nocode
I think the actual question people are wondering is - will no-code take my job.
TLDR -- No-code / low-code are basically just SaSS - you still need hire and pay software engineers to build it and use it. I do not predict that it will become a threat to employment or compensation, ever. Longer answer below:
Some of you who remember a time when developing software was really, really hard. The tooling and docs have only gotten better, and the barrier to entry is lower than it ever has been before - it is now easier to become or switch careers (me) into development. Has the compensation for developers fallen? No, we have just gotten more productive, but the demand for software has gone up a lot.
No-code / low-code are tools, and tools do not tend to replace people, but people still need to build and use the tools. Did AWS, kubernetes / docker, and Jenkins make IT and sys-admin folks less valuable? No, they just learned the tools and leveled up - now we call that "devops" and they get paid well.
TLDR -- No-code / low-code are basically just SaSS - you still need hire and pay software engineers to build it and use it. I do not predict that it will become a threat to employment or compensation, ever. Longer answer below:
Some of you who remember a time when developing software was really, really hard. The tooling and docs have only gotten better, and the barrier to entry is lower than it ever has been before - it is now easier to become or switch careers (me) into development. Has the compensation for developers fallen? No, we have just gotten more productive, but the demand for software has gone up a lot.
No-code / low-code are tools, and tools do not tend to replace people, but people still need to build and use the tools. Did AWS, kubernetes / docker, and Jenkins make IT and sys-admin folks less valuable? No, they just learned the tools and leveled up - now we call that "devops" and they get paid well.
It's stupid and doesn't really represent anything of substance
1) Don't write code
2) Automate transit
3) ???
4) Idiocracy.
Two amazing tools out there 1) oracle apex and 2) bubble.io
Reminds me of Frontpage, good enough until it is not.
272 comments and nobody mentioned a lollipop yet?
No-code is just a synonym for “software”.
I don't think it's a paradigm shift. There's always been a desire to have some sort of magical tool or platform that would eliminate the high cost of a developer. The problem that these companies encounter is that these tools are quick to improve the baseline but they come at a cost of making their baseline the same as other peoples baseline. If they want something unique, or compelling, that's above and beyond then they would need custom work and that means some form of development
Standard rants:
1) Every symbolic or visual representation of a command or control flow structure in a no-code tool is isomorphic to some construct in a programming language, just more cumbersome to author and manage, especially at scale. Therefore, users of no-code tools are programmers; they engage in programming when using the tool to define some process.
2) Programming with text can be done with a variety of tools, from full-fledged IDEs to Notepad. Programming with a graphical representation can be done only with tools that render that representation (usually, proprietary tools from the no-code tool vendor).
3) Text is more amenable to being diffed, transformed, and version-controlled than are visual representations.
4) Visual representations have a low complexity threshold beyond which they simply become unmanageable. It doesn't take long to clutter the screen and make it difficult to find what you are looking for and manipulate it. Some sort of normalizing or beautifying feature for the program control graph, as well as a search feature, may be added, but these are necessarily more complicated than their text-based equivalents.
5) It's much easier to simply type in what you want the computer to do than to engage in prolonged rat wrestling to construct a representation of the procedure to be followed.
6) No-code is circumscribed: If you are writing something the no-code tool author anticipated, you will be fine, If you are writing something the no-code tool author didn't anticipate, good frigging luck.
7) We've been sold this snake oil time and time again. It was CASE tools in the 90s. In the 2000s, we were literally told that programmers would be made obsolete by the emergence of UML to program conversion tools. (I had a professor who said as much, almost in so many words.) It never takes because with the complexity of real-world software, it becomes an ergonomic nightmare.
8) No-code is intended for two main audiences: as didactic tools for children or the barest of beginners, and as production tools for dilettantes who want to program without putting in the effort or assuming the stigma that professional programmers do. In a production environment, the output of these dilettantes will be abandoned by the dilettantes themselves, who aspire to grander things like marketing, management, or finance; and will instead have to be maintained by... professional software developers, who will curse the original authors' names forever -- thus nullifying one of the touted advantages of no-code to organizations: that you get the benefits of custom programming without having to hire programmers.
In short, in order to think of things more snake-oil than no-code, I have to go to the old standbys of medical pseudoscience and multi-level marketing products. I can see no-code used as a crutch by those who are new to programming and afraid to approach it, but they would perhaps be better served by using something that involves code, but tricks them into believing that what they're doing is not programming, thus alleviating their "programming anxiety". Secretaries were successfully trained to write rather elaborate Emacs Lisp on Multics Emacs back in the 1970s -- simply because they were told that in so doing they were simply customizing their editor, not programming it!
1) Every symbolic or visual representation of a command or control flow structure in a no-code tool is isomorphic to some construct in a programming language, just more cumbersome to author and manage, especially at scale. Therefore, users of no-code tools are programmers; they engage in programming when using the tool to define some process.
2) Programming with text can be done with a variety of tools, from full-fledged IDEs to Notepad. Programming with a graphical representation can be done only with tools that render that representation (usually, proprietary tools from the no-code tool vendor).
3) Text is more amenable to being diffed, transformed, and version-controlled than are visual representations.
4) Visual representations have a low complexity threshold beyond which they simply become unmanageable. It doesn't take long to clutter the screen and make it difficult to find what you are looking for and manipulate it. Some sort of normalizing or beautifying feature for the program control graph, as well as a search feature, may be added, but these are necessarily more complicated than their text-based equivalents.
5) It's much easier to simply type in what you want the computer to do than to engage in prolonged rat wrestling to construct a representation of the procedure to be followed.
6) No-code is circumscribed: If you are writing something the no-code tool author anticipated, you will be fine, If you are writing something the no-code tool author didn't anticipate, good frigging luck.
7) We've been sold this snake oil time and time again. It was CASE tools in the 90s. In the 2000s, we were literally told that programmers would be made obsolete by the emergence of UML to program conversion tools. (I had a professor who said as much, almost in so many words.) It never takes because with the complexity of real-world software, it becomes an ergonomic nightmare.
8) No-code is intended for two main audiences: as didactic tools for children or the barest of beginners, and as production tools for dilettantes who want to program without putting in the effort or assuming the stigma that professional programmers do. In a production environment, the output of these dilettantes will be abandoned by the dilettantes themselves, who aspire to grander things like marketing, management, or finance; and will instead have to be maintained by... professional software developers, who will curse the original authors' names forever -- thus nullifying one of the touted advantages of no-code to organizations: that you get the benefits of custom programming without having to hire programmers.
In short, in order to think of things more snake-oil than no-code, I have to go to the old standbys of medical pseudoscience and multi-level marketing products. I can see no-code used as a crutch by those who are new to programming and afraid to approach it, but they would perhaps be better served by using something that involves code, but tricks them into believing that what they're doing is not programming, thus alleviating their "programming anxiety". Secretaries were successfully trained to write rather elaborate Emacs Lisp on Multics Emacs back in the 1970s -- simply because they were told that in so doing they were simply customizing their editor, not programming it!
Software == a NO-CODE tool
Not a paradigm shift.
computers have become way more pervasive and basic coding actually isn't that hard. i think that maybe for all the hassles it creates when things get complicated, it may be secondary to next generation ides that make coding easier along with a general population that grows evermore tech savvy and ready to learn with each passing year.
tldr; i think it solves yesterday's problem. people today are both more willing and more able to learn basic coding skills. the hard part for both visual environments and high level languages is getting the abstractions right for the building blocks and i think it's an easier problem with the expressiveness of text.
tldr; i think it solves yesterday's problem. people today are both more willing and more able to learn basic coding skills. the hard part for both visual environments and high level languages is getting the abstractions right for the building blocks and i think it's an easier problem with the expressiveness of text.
I don't.
The problem with no-code is it is also usually no-ontology. It's always fun to mock 'ideology', but without a strong philosophical principle, every project will eventually morph into a hairball.
The underlying ontology behind code is, "reduce problems to a normalized form that can be stored in text, which we have gotten good at managing with snapshots and branches in DVCS".
With no-code, you don't have a normalized form to reduce to. Maybe your project is PowerBI modules or Excel-like superspreadsheets or whatever, but the 'stuff' that your project is made out of is not subjectable to the same kind of rigorous management that contemporary codebases tend to adopt.
The two analogies that come to mind are nosql, a movement which rather quickly discovered that RDBMS -- a normalized form for storing and addressing data -- was a pretty good idea, actually, for many use cases.
While NoSQL found important roles to fill, it is by no means as Big a Deal as the breathless tech media made it out to be, back in the aughts when mongodb first dropped.
The other analogy is double-entry bookkeeping. It's been around forever, and while it's not appropriate for every use case, its resilience and ability to represent complex changes in a complex system over time in a normalized way is similar to how a well-maintained codebase is represented by git (and competitors).
Code is a form for representing thoughts about changing systems which change the world in turn. It implies an ontology -- an "ideology", in the popular sense of the term -- and without that scaffolding, projects get floppy.
I'm much more excited about things like Git Copilot. Did you see the demo at Ignite, where that guy was literally just describing in English how he wanted the minecraft bot to behave, and the model wrote the (perfect) Minecraft scripting to make the bot obey?
That, IMO, is the future. Tools that create code that may or may not require tweaking, but can be still be committed to a repo, and is still something whose provenance and behaviour you can reason about, and diff-view when it changes.
Now, making the resulting code provably correct in a quick, automated way is probably the next thing I'd work on if I was in charge of Copilot development. But this will probably require changes to the languages that people use.
"Here is the code that does the thing you verbalized in English, here it is deployed, and also, here are several proofs, including a formal proof, the code does what is intended."
(Another advance I'd like to see are AST-based DVCS, rather than text diffs, but that is a story for another monologue)
[EDIT: I should mention that I happen to work at the specific Big Tech Company that makes Copilot; however, I work nowhere near the team that made it, and my opinions are emphatically my own.]
The underlying ontology behind code is, "reduce problems to a normalized form that can be stored in text, which we have gotten good at managing with snapshots and branches in DVCS".
With no-code, you don't have a normalized form to reduce to. Maybe your project is PowerBI modules or Excel-like superspreadsheets or whatever, but the 'stuff' that your project is made out of is not subjectable to the same kind of rigorous management that contemporary codebases tend to adopt.
The two analogies that come to mind are nosql, a movement which rather quickly discovered that RDBMS -- a normalized form for storing and addressing data -- was a pretty good idea, actually, for many use cases.
While NoSQL found important roles to fill, it is by no means as Big a Deal as the breathless tech media made it out to be, back in the aughts when mongodb first dropped.
The other analogy is double-entry bookkeeping. It's been around forever, and while it's not appropriate for every use case, its resilience and ability to represent complex changes in a complex system over time in a normalized way is similar to how a well-maintained codebase is represented by git (and competitors).
Code is a form for representing thoughts about changing systems which change the world in turn. It implies an ontology -- an "ideology", in the popular sense of the term -- and without that scaffolding, projects get floppy.
I'm much more excited about things like Git Copilot. Did you see the demo at Ignite, where that guy was literally just describing in English how he wanted the minecraft bot to behave, and the model wrote the (perfect) Minecraft scripting to make the bot obey?
That, IMO, is the future. Tools that create code that may or may not require tweaking, but can be still be committed to a repo, and is still something whose provenance and behaviour you can reason about, and diff-view when it changes.
Now, making the resulting code provably correct in a quick, automated way is probably the next thing I'd work on if I was in charge of Copilot development. But this will probably require changes to the languages that people use.
"Here is the code that does the thing you verbalized in English, here it is deployed, and also, here are several proofs, including a formal proof, the code does what is intended."
(Another advance I'd like to see are AST-based DVCS, rather than text diffs, but that is a story for another monologue)
[EDIT: I should mention that I happen to work at the specific Big Tech Company that makes Copilot; however, I work nowhere near the team that made it, and my opinions are emphatically my own.]
To me it sounds like communism: utopian in imagination, dystopian in reality, both inevitable and impossible at the same time.
nocode === IDE
no-comment
At welovenocode.com (the biggest no-code marketplace) we discovered that during shortage of software developers, big companies (S&P 500) started to hire no-code devs instead. The ratio of code to no-code people hired was 1000:1 and now it has increased to 100:1 (by 10 times)
I think that within a couple of years, no-code will take over >30% of the software development market
I think that within a couple of years, no-code will take over >30% of the software development market
I've been waiting for a (popular) low-code movement to hit the backend. Right now we still seem to start every project with - auth,connections,server, etc..
Something like https://github.com/oshalygin/gqlgen-pg-todo-example but easier and more tied into everything already.
Effectively instead of hand coding up the stack, there would be this server that you install and you get auth (implying a user model), GQL, and all you have to do is make the database and define a special file that tells the DB what is viewable or restricted and how that connects to the user.
The package would be 100% open source but would have like modules you could enable to connect it to auth0 (or others) or use a pre-created schema.
That's the stuff that should have been turned to low code by now and I still don't see much progress.
Something like https://github.com/oshalygin/gqlgen-pg-todo-example but easier and more tied into everything already.
Effectively instead of hand coding up the stack, there would be this server that you install and you get auth (implying a user model), GQL, and all you have to do is make the database and define a special file that tells the DB what is viewable or restricted and how that connects to the user.
The package would be 100% open source but would have like modules you could enable to connect it to auth0 (or others) or use a pre-created schema.
That's the stuff that should have been turned to low code by now and I still don't see much progress.
I'm fundamentally opposed to outsourcing myself or other engineers either now or in the future either to AI or to no-code tools. I don't like the way this industry treats their employees in general nor am I very fond of the idea of using engineers to create a tool to make them obsolate. No thanks.
Like most things in SV, people get hung up on the term.
I like the tools coming out. UX designers, Airtable, etc. I don't view it as nocode, simply as developer and business tools.
I like the tools coming out. UX designers, Airtable, etc. I don't view it as nocode, simply as developer and business tools.
I've been working in the development space since 2015 and recently joined fast-growth no-code startup (https://welovenocode.com). We just raised $1M and achived $150K MRR. Happy to share my opinion based on my experience of leading "code" and "no code" startup.
No-code is basically the art of creating solutions (native apps, websites, web apps), which could have been written with code but instead using visual methods (without coding). Most no-code tools use a visual drag-and-drop interface. A lot of them have pre-built templates that you can customize. There is also a slight difference between "low-code" and "no code".
With "low code" a lot of things can be done with a drag-and-drop interface, however, some coding is required to for a finished product. So you ANYWAY need some background in coding. This is typically great for people with intermediate technical skill.
What can be built with no-code?
Mobile apps, web apps, websites, workflow and automations, marketing tools, payment systems, and the list goes on. Basically, "typical" products & MVPs benefit the most from no code. So founder can built something in weeks, really fast. For example, WeLoveNoCode (https://welovenocode.com) connects founders with the best no-code developers to build their software and apps without a single line of code in like 10 days. All that is based on a monthly subscription.
Why all the hype?
Well, ho code has A LOT of the advantages:
- will save you money
- You can build and test your ideas quickly
- Anyone can use it > Designers, product managers, marketing managers now have the ability to make their ideas tangible products.
What are the challenges you may face?
Just like new thing, tools have to be learnt and they all have their learning curves. However, it will take you much less time and resources learning how to use no-code tools. Unlike low-code tools, no-code tools have a limit to how much they can be customised. If you want to change every aspect of your product or want to build very complex products, no-code tools may bring some limitation. However, there’s so much innovation and growth with these tools so I expect these barriers to reduces in a few months.
I should add that there’s no limitation with scalability. No-code tools have the capacity for serve increase to allow as many users as possible without breaking. These tools are also very secured.
No-code is basically the art of creating solutions (native apps, websites, web apps), which could have been written with code but instead using visual methods (without coding). Most no-code tools use a visual drag-and-drop interface. A lot of them have pre-built templates that you can customize. There is also a slight difference between "low-code" and "no code".
With "low code" a lot of things can be done with a drag-and-drop interface, however, some coding is required to for a finished product. So you ANYWAY need some background in coding. This is typically great for people with intermediate technical skill.
What can be built with no-code?
Mobile apps, web apps, websites, workflow and automations, marketing tools, payment systems, and the list goes on. Basically, "typical" products & MVPs benefit the most from no code. So founder can built something in weeks, really fast. For example, WeLoveNoCode (https://welovenocode.com) connects founders with the best no-code developers to build their software and apps without a single line of code in like 10 days. All that is based on a monthly subscription.
Why all the hype?
Well, ho code has A LOT of the advantages:
- will save you money
- You can build and test your ideas quickly
- Anyone can use it > Designers, product managers, marketing managers now have the ability to make their ideas tangible products.
What are the challenges you may face?
Just like new thing, tools have to be learnt and they all have their learning curves. However, it will take you much less time and resources learning how to use no-code tools. Unlike low-code tools, no-code tools have a limit to how much they can be customised. If you want to change every aspect of your product or want to build very complex products, no-code tools may bring some limitation. However, there’s so much innovation and growth with these tools so I expect these barriers to reduces in a few months.
I should add that there’s no limitation with scalability. No-code tools have the capacity for serve increase to allow as many users as possible without breaking. These tools are also very secured.
Fusion. Artificial general intelligence.
Much ado about nothing
Some seem to supplement developers (eg: retool) and some empower non-engineers to be able to build websites/apps/integrations without necessarily having a developer in the loop (eg: shopify/zapier/airtable).
What do you think about this movement? Clearly these apps/platforms enable non-developers to solve a bunch of problems which would otherwise need a software engineer. Is this a paradigm shift?