What do you think about the no-code movement?

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.

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.

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.

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

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.

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

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.

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

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.

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.

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.

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.

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.

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

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

Someday it might happen, but the problem is being specific enough:

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.

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,

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.

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

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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…

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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

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

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.

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.

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.

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

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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.

I tweeted this (https://twitter.com/kristiandupont/status/136269830566755123...):

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

My hot take: No Code, from a non dev perspective, is just a really user hostile config interface.

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.

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.

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.

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

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

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.

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.

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.

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?

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.

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.

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.

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.

Zapier is a god-tier tool for all kinds of corporate work, and companies that ban it for "security" reasons are shooting themselves in the foot.

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.

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.

Everything about no-code screams vendor lockin. It's stupid and I'd never use or recommend these things.

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

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.

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?

Fusion. Artificial general intelligence.

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!

Software == a NO-CODE tool

Much ado about nothing

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.

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

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