Ask HN: What do you think about the no-code movement?

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.

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 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.

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

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.

COBOL is code - it's not nocode.

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.

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...

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.

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.

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

> 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.

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!"

COBOL isn't older than all of us!

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)

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.

+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.

[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.

well said!

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

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

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

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

- The Tao of Programming (1987)

I remember 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.

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.

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?)

> 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...

> 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.

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.

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.

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

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.

> 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.

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.

""" 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.

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.