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

I recognize COBOL may not seem like "no-code", but that's just because "no-code" is a stupid label. "No-code" doesn't mean "no code" just like "serverless" still runs on a server.

I would say the main problem with the no-code hype is the idea that it is a leader. It is not. It is a follower. "Normal" code goes out, hammers things out over the course of literally decades, and then, when it has finally settled what the best couple of ways to do something is, it's finally time for the "no code" solutions to come in and systematize that for a larger audience. Nothing wrong with that. Power to the people and all that.

It just goes wrong when no-code advocates put the cart in front of the horse and make grandiose claims about replacing all developers or something. That's not the direction the stream flows in. No-code can't operate without the "normal" developers doing immense amounts of work charting the territory and building the infrastructure to get there. There is no chance of them displacing "normal" software developers; they are structurally incapable of it. Woe unto the no-code startup that doesn't understanding this dynamic, and foolishly tries.

Things we disagree on: code before no code

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

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

So where and why to use no-code?

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

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

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

So essentially, the company gets version 2 of the code, at the cost of 1x user time + 1x developer time. Instead of version 2 of the code, in 2x developer time, which is too expensive and never happens.

* From a TCO, maintenance and reliability standpoint

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

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

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

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

[0] https://hn.algolia.com/

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 heard a great quip at some point: "Why is Excel the most useful IDE?" Answer: "Because it's the one IDE every business allows every user to access."

Most of us here have forgotten that many businesses flat out ban access to programming tools for the majority of users.

And what is an enterprising user to do, when they realize they're performing the same process 100 times a day?

Reach for the only wrench they've been given access to.

PS: I guess an analogy would be people griping about shell scripting, without considering that someone might not have the ability to install their framework of choice when connecting into a client server. It gets the job done, with the tools available.

1) This industry absolutely has the capability create more tools like Excel that are both extremely empowering and orders of magnitude easier than what we think of as coding.

2) Unfortunately, there's a strong, likely frequently subconscious, incentive to definitely not do this, since it carries a strong danger of IT making itself "obsolete."

(Not judging here, just observing)

With that in mind, it's interesting that we still even have "general-purpose programming languages." There is some specialization for sure, but that's partly because of things like e.g. the browser only supports Javascript. And then you see things going back the other way, e.g. with NodeJS.

So I'd wait till we see some actual, real specialization in the languages / tools that engineers use, beyond "ecosystem" reasons. In the meantime, we've seen tools that help non-programmers "automate" things. Everything from CAD to Wix, Salesforce, Figma, etc. would fall under that umbrella. But then you still have code. If what you want is automation / labor-force-multipliers, the common denominator will still be highly generalized, and therefore, hard.

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.

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.

However, their wants always grow just beyond the no-code capabilities, and there's still a need for software engineers for things that haven't been fully solved yet.

Both as a no-coder and a user.

As a user the UX is horrible and I’m now swamped with terrible “apps” or “workflows” that people try to get me to use and fail for arcane reasons. Or are just ugly or brittle.

As a no-coder the tools are hit or miss, the docs are bad, and widgets frequently don’t work due to my licensing and there’s no way to know other than to try and see.

It has such promise as the shell scripting equivalent for the cloud what shell was to PCs. But instead it is a costly and difficult thing to use.

Since you're using PowerPlatform you can prob easily do that with Microsoft's Power FX, built - I believe - especially for this.

https://docs.microsoft.com/en-us/power-platform/power-fx/ove...

More about being in a right place at a right time, but granted.

> Having said that, I have been working with Microsoft PowerAutomate for the past 1.5 years and while it has saved a lot of time and been overall a good experience, there are times when the no code/low code gets in the way and I wish I could just "drop into code" to get something done. Examples are things like data validation. This technology is not going to replace coding, the paradigm shift is really happening for people in the marketing and sales operations parts of the business. For these folks, this tech is life changing. In a lot of ways, this tech felt like when you try a new framework in your language of choice; at first it's super easy and you get hyped, and then you hit a requirement where the nocode/lowcode environment really gets in the way.

I think higher-level languages with a dual code-graphic representation and a possibility to drop into lower level are an interesting option, but even that is not new - Unreal/Unity3D etc.

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.

If you needed a GUI for database CRUD operations (which is a lot of business processes and a lot of webapps now), then you could do that with nearly zero code, as the built-in behavior was all that you needed, but if you needed some interesting custom script and just a button "run it" and a textbox for results, then of course that would be nearly all your own code.

Today I was thinking about Visual Basic 6, which worked more or less the same way.

I wonder what similar alternatives we have today? Gambas? https://en.wikipedia.org/wiki/Gambas

Even video games these days need to adapt to a different UX on each platform even thou they are the closest to having one unified UI across the gamut

Giving up on the desktop is a huge step backwards.

Isn't that a solved problem by the likes of React Native?

The most rapid UI tool I've ever encountered is Tcl/Tk. Everything else involves incurring more tedium and misery -- even Visual Basic or Delphi.

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.

Programming is just a tool as well... there's a odd distinction here that somehow more specific tools are lesser. I also think this is where the whole #nocode thing can go wrong. You should empower non-programmers in ways that suit them.

> You can maybe prototype a game mechanic if it’s not very unique with drag and drop but it’ll never scale to production.

The expressiveness of composition is only limited by the number of elements you have to compose. In the specific zombie case no it wouldn't scale to production. But then the prototype wasn’t meant to and also would never have existed if it weren't for these tools. We unlocked the ability for our Art Director to prototype a new game all by themselves. That's massive from a creativity point of view. We'll almost certainly turn it into a full game at some point.

From a production standpoint a game is thousands of special data cases. Which is why tools are so important and code is both data and a tool but if you can simplify things so much the better.

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

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.

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.

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.

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

For making a website with a store though, it can be great.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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

I think a lot of the problem is the endless hype and over-promising by marketing and sales people.

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

This would really clear me up for valuable work instead of having to rehash the same quick fixes for broken data modeling paterns.

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.

That being said, one feature of FME that I do use a lot is that at any point you can drop in a PythonCaller which lets you execute arbitrary python code on your data. Invaluable for the last 5-10% which cannot easily be done using the "no code" approach

I think that within a couple of years, no-code will take over >30% of the software development market

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 wonder if programmers of the day thought that compilers would put them out of a job?

Fred Brooks essay "No Silver Bullet"

http://worrydream.com/refs/Brooks-NoSilverBullet.pdf

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.

While I do primarily backend data work these days, I spent a lot of the early 2000's working for an agency that built websites for people and companies. Many of which would have been simple enough to throw together in Squarespace.

I'd always thought I could fall back into building websites if this didn't work out, but I feel like that's falling out as my backup plan. I still try to keep up on CSS and JS though, just incase.

I freelanced designing and building websites in the '00s before gradually migrating into in-house creative direction and product design. After getting burned out doing that, I've tried to start a little solo web and brand shop again, which sounds fun on paper, but I can't find a market for it. People just want inexpensive Squarespace editors. They look to Fiverr, Upwork, etc.

It reminds me of the Wordpress-only shops that drove me to in-house/product design in the first place, but with even less custom work being done.

It's a loss for web as a creative platform, and has left me unsure of how to proceed professionally.

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.

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

Just: SQL tables, prettified CRUD on those SQL tables on the frontend (with R/W permissions per user on tables), and reports (either on-the-fly or SQL queries run on a cron schedule).

Supabase is pretty much the backend piece of this (built around PostgREST), all it needs is a frontend generator that fits with its DB conventions.

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.

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.

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.

if you want to build something cool now it had better do more than update a database

-- You have to enter the information in yourself, or your equipment currently captures it for you

There are still CRUD opportunities where you find, capture and enter the information on behalf of the user. The phone captures a lot of data, so all that is already CRUDed up, but if you had novel data -- say from a wearable device -- you could still produce a new CRUD for that.

I think this is why hardware is hot again. It allows us to automatically capture new data that isn't already captured by the phone.

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.

I was using it in 1990 to build nocode distributed replicated GUI form and view driven applications.

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 have personally seen entire departments move from pen and paper to off-the-shelf boxed software to SaaS and now to no-code apps. You can finally customize your software exactly how you like without hiring a team of developers, and that's a great thing.

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

Over time all software areas will have no-code options.

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

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

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.

Exactly.

C++ is no-code if you work in x86 assembler.

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.

I created an email escalation notification system that was manipulated with graphics in a flow diagram. My users couldn't handle the precise logic for doing the escalation chain and always asked for help. Turns out, _that's_ what I'm good at. Logic and abstract reasoning.

You don't need to write code to modify it, but if you have no knowledge of flows or state machines or logical succession of events you simply can't solve the problem. It's not hard, but no-code isn't going to make it less hard either.

I think in a few years (decades?), "developer" and "programmer" will mean something very different that they do today.

The hard part of programming is computational thinking, and coming up with novel ways to string the right algorithms together to get the result the client needs, not typing vs dragging and dropping.

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.

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.

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.

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.

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.

The machinery behind web sites outside of the top 100 ought to be standardized by now.

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.

Code is going to be the most efficient way to express and verify that logic.

I've spent the past 1.5 years or so building a no-code data analytics tool called Mito [1] -- a spreadsheet extension to JupyterLab that lets previously Excel-based workers make the switch to a Python based environment. Unlike other no/low-code data analytics tools we spend a large amount of engineering time making sure that users are never locked into Mito. We do this in 2 ways: Firstly, every time you make an edit to your data in the Mito spreadsheet, we automatically generate the equivalent Python code for you. And secondly, to make it easy to work with that code, Mito is an extension to your JupyterLab environment. By existing in the IDE that you would otherwise be using if you didn't have the low-code environment, its really easy for users to switch back and forth between working in the Mito no-code environment and writing code themselves.

Practically, what we've seen over the past year is that giving users ownership of the code that they create using Mito and existing in JupyterLab has been incredibly important. The most active Mito users are those that use Mito in conjunction with custom Python code that they or their company has written. They do things like incorporate API calls to access their data, use advanced pandas/Python functionality that we don't support, etc.

TLDR: We believe that no/low-code are most powerful when they are augments to the "real deal" code-first workflow instead of a substitution.

[1] https://trymito.io/hn

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

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.

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,

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!

Something like https://github.com/oshalygin/gqlgen-pg-todo-example but easier and more tied into everything already.

Effectively instead of hand coding up the stack, there would be this server that you install and you get auth (implying a user model), GQL, and all you have to do is make the database and define a special file that tells the DB what is viewable or restricted and how that connects to the user.

The package would be 100% open source but would have like modules you could enable to connect it to auth0 (or others) or use a pre-created schema.

That's the stuff that should have been turned to low code by now and I still don't see much progress.

I like the tools coming out. UX designers, Airtable, etc. I don't view it as nocode, simply as developer and business tools.