Probably because no-code/low-code has been hyped since the 1970s, with the prediction that companies won’t need programmers anymore. End users will do their own programming. AI will write code better than human programmers. The work will get outsourced overseas. Software development and maintenance represents a big cost and significant risk to many companies so they eagerly lap this kind of thing up. COBOL and SQL both got pushed as low-code/no-code solutions and you see how that worked out.

Tools and services that package something like notifications up for easy integration are not really low-code/no-code. Useful tools and services save development time but that doesn’t mean they eliminate programming jobs.

I’ve been programming for over 40 years and have heard the no-code/low-code predictions since I started. The day I see a manager or end user with no programming skill and experience do my job with some connect-the-dots visual tool or AI I’ll retire. I don’t expect that will happen anytime soon because translating algorithms to a programming language is not the hard part of programming.

> translating algorithms to a programming language is not the hard part of programming

I agree with this bit, but often struggle to verbalize what is hard. I'm curious to hear your take.

I usually say, in a hand wavy way, that structuring large logical processes takes a lot of deep concentration, but that doesn't quite capture it.

You might know the old joke about the factory that breaks down, costing thousands of dollars an hour. No one can figure out what's wrong. A consultant is brought in, he spends a few minutes analyzing the problem, then pushes a button and the factory starts back up. He presents a bill for $10,000. The owner balks -- $10,000 for less than an hour of your time? The consultant says the time is $1, the other $9,999 is for knowing which button to push.

When someone hires me to solve a business problem with software they aren't paying for my knowledge of Javascript or C++ syntax, or how to implement a linked list, or call an API. They are paying for a solution to a problem, and solving that problem means I need to understand it and draw on my experience and expertise. Sure, anyone can learn Python in a couple of weeks and get "Hello, world" to work (I've taught teenagers Python programming myself). But there's a big distance from there to solving actual problems with software, and adding value to an organization with programming skills.

Anyone can learn how to sum a column of numbers or take a blood pressure reading in a few hours. That doesn't make them accountants or doctors.

Different problems and business domains have varying degrees of difficulty. In general the hardest problems are:

- Defining requirements as completely and unambiguously as possible.

- Breaking requirements down into tasks suitable for estimation and implementation.

- Deciding on appropriate data structures, i.e. a relational database schema.

Inexperienced developers (which would include much of the target market for low-code/no-code tools) often make obvious mistakes: failure to test adequately, missing edge cases, not understanding security, implementing fragile and low-performance solutions, etc. They also usually have no idea how to approach debugging a problem, or even describe a problem -- anyone who has worked a help desk or had to respond to trouble tickets knows that.

Excel is a classic no-code/low-code tool. If you have ever had to review and debug spreadsheets put together by non-programmers you have seen what happens. The tool itself is very powerful and non-programmers can get a lot working, but on inspection you find formulas with errors, poor performance because of ad-hoc organization and data types, hard to reproduce bugs, etc.

I have worked with a lot of WordPress sites put together by small business owners and marketing agencies. WordPress is a low-code/no-code tool -- almost anyone can get a basic site up and running using a hosting provider, and install any number of themes and plugins to add functionality without any coding. But as soon as something goes wrong, like incompatible plugins, or some integration is needed like pushing sign-up forms to a CRM, the amateur developers are stuck.

No doubt there's lots of low-hanging fruit. I don't have a problem with non-programmers using tools like Excel or WordPress to solve their business problems, or even writing small Python scripts to automate something. That's not really what I do, and I know they will hit a ceiling pretty fast where they get in way over their head with how to define a problem, decompose it into tasks, algorithms, and data structures, implement in an organized way, test, debug. I can get so far with working on a car or motorcycle with my limited mechanic skills, but more often than not I need a professional with the right tools, expertise, and experience because I quickly get in over my head.

In my experience, devs that have interacted with no code and had negative experiences tend to fall in a few categories:

1. Used it themselves and didn't move any faster because of having to learn a new way of thinking

2. Used it themselves and tried to do something that seemed reasonable to them but the no-code couldn't handle

3. Had a no code solution built elsewhere in a company dumped onto them for maintenance, or to be implemented into an more robust product. I've seen this play out as:

- Marketing/Sales "this mostly working and critically important to our pipieline, fold it into our system and add these 3 features. ETA should be like 2 weeks right?"

- Engineering "what is this? I've never heard of it. It's going to take like 4 months to fold it into our system properly and add those features. Why didn't you ask us to build this from the start? It would have taken way less time."

- Marketing "You said it would take a month to complete, and a month before it would be prioritized. We needed it in a week so we did this. If it only took us a week why will it take you months?"

1 and 2 are mostly folks who aren't the right target market, they're right and also they don't really matter unless you're trying to target those devs specifically. 3 is a real concern, because those are the devs who will campaign furiously against a product in meetings, getting burned by that once sticks around for a long time. And both sides of the conversation in 3 are often correct from their perspective, which makes it even harder. A no code solution that actually has an off-ramp to a more robust implementation would be an amazing way to deal with that, but that might always be against incentives.

I'll expand on 2.

> I work for a SaaS product that enables developers to build app-to-user notification systems with minimal code, which I think it genius.

That sounds like an interesting problem, and one that is relatively well scoped. It's a good candidate for a low/no-code approach.

> I really just want to understand what their concerns are and why the idea of a low-code solution for developers can seem so threatening

Wouldn't use the word threatened.

Low/No Code always gets you 90% of the way. Then remaining 10% are a nightmare to deal with since you now need to extend a tool that really wasn't built for it. To do so it's always custom languages, proprietary extensions and plugins, obsolete or incomplete doc. And don't forget all your work can be undone in a single breaking update from the vendor "Ohh sorry we deprecated that API because there was nobody except you using it".

It depends on what no-code/low-code is used for.

When used properly, no-code and low-code platforms are great. They let a much broader population of non-developers build things and automate workflows. Even for people with an engineering background, they're often just simpler and faster to use than writing code from scratch. One of the best uses I've seen for these platforms is when prototyping a new startup or product idea–you can invest a few hours of work to build something that can demonstrate a proof of concept.

However, the vast majority of the time I see low-code platforms being used at scale in an enterprise setting, they're being used in ways that create more problems than they solve. The core problem is that these platforms aren't built in a way that encourages maintainability and collaboration at scale.

Why? When using a no-code/low-code platform, you're still building software, even if you're not writing a single line of code. And if you're trying to collaborate on that software with other people, you'll want things like version control, code reviews, unit testing, dev/prod environments, etc. Most NC/LC platforms don't provide any of this.

I'm working on a startup, https://www.airplane.dev/ where we're building a platform that lets people create internal tools more easily, and it's technically a low-code approach, but it's very different than most of these "siloed" app builders out there. You can express everything as code and version control it, write unit tests against it, etc.

Potential risks:

- Vendor lock-in: if each low-code platform offers a different set of components and workflows, then it may be difficult to move to another if, for example, product cost becomes prohibitive at a later date.

- Dishonest platform: unless the product provides an on-premises option (and many likely won't, partly because it is genuinely easier for users to get started with a cloud option), then both code and data is potentially available for the platform to inspect.

- Business continuity risk: as with the previous risk, this depends on the availability of on-premise hosting (and/or product code available as FOSS run-it-yourself): if the low-code provider ceases to exist, then your business process (or perhaps entire business) may fail.

There are some slightly more technical concerns that I have too:

- Testing and source control don't always seem apparent or well-integrated, making me think that we are going to repeat some of the software engineering mistakes of the past.

- Depending on the concepts and components exposed by low-code platforms, expressivity and capability can be (intentionally or unintentionally) limited. Integrating with an arbitrary weather forecast API that speaks an arbitrary protocol is possible using a generalized programming language - is it equally possible with each low-code platform?

Democratizing technology is important and low-code will I'm certain help discover some excellent workflow improvements.

However I think it is equally important to make it simple for someone to pick up a programming language -- that supports testing, source control, and so on (without requiring the user to know about them, initially...) -- and start on a path that will lead them towards established and recognized best-practices and an open, competitive ecosystem.

I've been a proponent of low-code in the past (and may well be in the future), but we've been a bit burned recently with one of our suppliers - and it's not really a technical problem.

Low-code platforms tend to come with complex licensing agreements, typically with variables for the size of the functionality developed, and the number of users - this left us in a sticky place when the supplier increased the cost for the functionality delivered without significantly increasing value delivered. Like all agreements, there are things you can do to increase value without exponential increase in cost, and we've done some of these.

So the real issue is that the application architecture becomes license-driven rather than best-practice driven, and we paint ourselves into corners and reduce the overall value of the solution because of this.

So my advice is not to avoid, but when you do proceed make sure that the cost increases are limited to CPI (or similar) for the same functionality (and don't factor an expiring discount into your ROI calculation - make sure it's worthwhile at the non-discount price).

We've also had issues with branching, merging and version control, but that's secondary to the license-driven architecture problem.

I find Microsoft 365 Power Automate to be a satisfying tool for low-code-ish "glue" processes. But to effectively replace hand-coded solutions, you still need to know the basics of things like HTTP requests/responses, JSON, conditional logic, looping, error handling and how to read/edit function parameters. So its value for me is more about taking care of boilerplate/hosting. The alternative would be VBA, which I've not really written on the job, so much as inherited someone else's business-critical rats-nests.

The real benefit of no/low code is giving the 5% of users in my org who care enough a way to make their mental maps of business processes explicit and shareable. That way if we outgrow no/low solution we have a sketch for a tool needing custom development.

Generally, no-code solutions tend to be limiting. With code, you can build whatever you want. With no-code, you can configure whatever the people who wrote the code enabled as a configuration option.

Usually, no-code solutions are a great way to get started easily and cheaply at the beginning when you don't need everything and time is precious because you are so terribly short-staffed. The risk ends up being that, down the line, you're dependent on this thing that can't be made to do the things you now care about, and you have to spend a fortune and risk breaking your core product, to excise the no-code thing and "build something real"

As a marketer, who is fairly non-tech, think it's not as simple as marketed (the irony). Some tools that help you do very basic stuff like Softr are good for testing a simple MVP, but anything a little advanced would need some dev help even on the no-code tools. Guess useful if you know how to code or need something super simple, otherwise not so much.

No-code and low-code platforms are incredible. I don't think you'll receive a fair answer to the question here. These platforms are most valuable for non-technical people, particularly founders who are looking to build an MVP. These platforms are even more useful if you don't have a network of technical friends/colleagues. There are relatively few people that fit that description here on HN.

Nobody thinks that you can scale the next Amazon.com on no-code platforms. However, if you're just starting out and you want to demonstrate the value of an idea without hiring a developer or learning to code, these platforms are a godsend. They've enabled an entirely new segment of the population to develop tech, where previously they would not have been able to.

I'd like to see examples. I'm only aware of landing pages put together from off-the-shelf themes, which I wouldn't call "tech," though it often passes for an MVP these days.

Does makerpad.co count as an example? The entire company was built using no code tools then sold to Zapier recently for an undisclosed amount:

https://techcrunch.com/2021/03/08/zapier-buys-no-code-focuse...

Makerpad looks like a no-code tool, not something built with no-code tools. Their job board shows they are looking for traditional programmers with Java and similar skills.

At first glance it looks like they’ve reinvented HyperCard (circa 1989) or something similar, but for the web. Dreamweaver (now an Adobe product) came out in 1997, got lots of use back then, but I haven’t seen anyone using it for a long time.

This space is fairly well explored and has been for decades. That doesn’t mean the tools are useless, but I’m not seeing the big innovation that will let non-programmers write sophisticated software.

I am currently searching for the article where talks about the fact that makerpad was in fact built with no code tools. I probably won't find it in time for the comment section of hn though.

I am personally hopeful about GPT-3 The two tools I'm familiar with TabNine and CoPilot both look great and seem easy to use. Maybe they will change your mind.

If the tools are useful to their target market, great. I've seen lots of these things come and disappear. Some of them seemed useful and actually made software development accessible to non-programmers -- HyperCard and Dreamweaver, for example.

You don't need to change my mind. I'm a professional programmer and none of the work I do is in the domains no-code/low-code tools (or even less, GPT-3) are aimed at. These things don't threaten my livelihood; my experience has been they create more work for skilled programmers.

They probably do, but honestly when I mentioned changing your mind I was aiming more for hoping that you might see a benefit to the type of things that QuickBase is currently enabling. For a marketing person not to have to wait months to get on the radar of "professional programmers" is a game changer. Bottlenecks do occur and there are probably/definitely not enough programmers of a certain quality to go around.

Also, there is a lot of programming to be done at all levels of skill. We have barely scratched the surface of the stuff that needs to be done...even a non-techie like myself can see that. So some of it will have to be done this way or it might never get done at all. That would be a real tragedy.

I don’t disagree that some of these tools might be useful to non-programmers. I disagree with the worry that such tools threaten the jobs of professional programmers.

Ah, thanks for clarifying.

If you are marketing to the right audience, then ignore the fuzz. In my experience, most solutions aren't marketing to the correct audience.

In the Quality Engineering/SDET realm, I get dozens of emails a week for low/no-code solutions around test automation. I get at least one or two calls a day from someone pitching their solutions. I don't care about their no-code RPA solution because I've got fantastic engineers writing actual code.

If they knew their market, they would target the finance users, the ERP systems, the SFDC and SAP engineers, or the manufacturing bridge groups. Places where they could actually get a sale from individuals who want to bridge the technical-automation gap.

Zapier, a popular no-code platform, has made a very specific segment of computer consultants redundant, and that's very threatening to that segment of developer. You can argue around that all you want (what about retraining, or a rising tide lifts all boats, or that a better dev experience is a better dev experience), but no-code is fundamentally threatening to those who've spent their careers, often ones that predate stack overflow, leaning to program.

If someone's career depends on them not understanding something, they won't.

I think low-code/no-code is misleading since it means vastly different things.

For example, Zapier is a flow automation tool in the broad RPA category - they automate triggers and steps between different existing applications. The "code" version of these things is usually data integration plumbing that be built as a FaaS in a few weeks.

This is completely different from say, Salesforce or Dynamics 365 apps, also low-code/no-code but where the platform's goal is to build applications tailored to your requirements using the platform's customizability, database included. The "code" version of these things are fully fledged web applications that take months or years to build. This is a much higher bar to meet for these platforms.

Funny, because Zapier (and Salesforce, WordPress, HubSpot, ActOn, etc.) have all created more opportunities for me as a freelancer/consultant. It's not that the tools aren't useful, or that the people using them are dumb. They create work for me in the same way I created work for my plumber trying to install new kitchen fixtures myself -- I could get fairly far with it but the remaining problems were the hard ones that a professional wouldn't have created themselves.

I'm non-techie. I am probably like 80% of the population when I say : even the low code stuff is difficult. The real issue is feeling like you need a map.In other words, this functionality goes here, that functionality goes there etc. It seems necessary to have some sort of compiler that lets you know the order of things. But no one ever discusses this when they talk about coding or building.So the mysteries are why some of these things don't reach the traction that they probably should. Solve the mysteries for people. Don't keep so many secrets because you think it will make us want to hire you or whatever. I have a ton of projects sitting on my laptop that I should probably be hiring someone to build...but I won't because every time I have a conversation with someone techie....it makes steam come out of my ears and raises my blood pressure 100 points. People did the same thing in the 80s with their vcr clocks....they'd rather just watch them blink than get someone to fix it.

Yes coding is a different language than most people are used to speaking, but it isn't as difficult as some like to make it look. And the average person would rather do something else (rather than sit and type all day).

In the end, I'll probably use Budibase because it's FOSS and it seems more like the needed framework than the others.

But the hate shouldn't surprise you...devs have been told for years that they were the Kings of the castle....and power concedes nothing. Anything that is perceived to reduce their power will be bashed.

>> Yes coding is a different language than most people are used to speaking, but it isn't as difficult as some like to make it look.

I'm afraid that You are mistaken - literally no one tries to make the coding (or rather software development because coding is only one step of it) more difficult than it is.

The thing that You missing is that the language of coding is like no other because the receiver of ot is different. There is no human on the other side (lets ignore collaborative nature of bigger projects for the sake of simplicity). The computer will only do EXACTLY what You ask him to do. Nothing more and nothing less. And this is key to understanding where most of the complexitu comes from - most of us do not have to ability to speak precisly and completly. We are mostly able to bubble about the things that are somehow similar to things that we think we need.

"because every time I have a conversation with someone techie it causes steam to leave my ears and raises my blood pressure 100 points."

This is not an argument, just description of your immaturity (defined as a lack of control of emotions). You are not going to get far if you are not willing to try to understand the other side and adapt.

I am able to talk with all kind of people and believe that at least trying to get into shoes of other person is the key to beneficial cooperation. Without it we are risking conflict escalation. And don't get me wrong - I completely understand where Your frustration is coming from (I had my fair share of introvert programmers to deal with) but I always try to not get overly emotional, and with a little bit of self control this can be done. Just don't expect that the other side will read You mind if You are not willing to read their.

Yes, I really enjoy being insulted by perfect strangers on the interwebs. It definitely motivates me to continue conversations. /s Please don't ever respond to anything I write again. I just can't handle it./s

>> It definitely motivates me to continue conversations

So get a thicker skin?

>> Yes, I really enjoy being insulted by perfect strangers on the interwebs.

Ok, your loss. I will give You a little secret about communication with people in IT (or rather STEM in general). The things that we are saying more often than not are not intended as an insult but only as an opinion, statement or diagnosis. Don't mistake directness for rudeness.

Yep, I'm probably going to take advice from you.

And truly I care more about the curation aspects of HN than I do about having conversations with tech people. I remain convinced that for the most part it is a colossal waste of time. Very little listening happens.....

I think the backlash is due to two things: the audience and the limitations no/low-code solutions often have.

Having worked at Microsoft on VBA-related things, I can attest without a doubt that no code automation (e.g. record a macro) are extremely powerful. VBA did give you the right tooling allowing someone with no coding experience to start tweaking macros generated by the recorder. The macros created by these often end-up being business critical. After having talked to so many huge customers, I'm convinced VBA powers at least a single-digit percentage of the world's economy.

That being said, the code of the macros often end up being a huge unmaintainable mess. Creating a lot of aversion from actual pro devs to it.

No-code solutions also end up being great for a few use cases, but fail at making complete products. It's the classic 80/20 problem where the last 20% still matters a lot. As soon as you want to step out the the guard rails, you often hit a wall.

I think no/low-code can be great and actually think VBA was awesome (well, not the language, but the platform). But, after having seen so many platforms that can't do anything more than a simple demo, I don't blame people for being doubtful about them in general.

Others have covered much of this but the biggest issues I've run into with low code solutions are:

- Lack of good versioning / source control

- Poor support for 'schema changes' / data migrations

- Running into limitations that prevent you doing something you really need to do and not offering a good 'escape hatch' to extend with custom code

- Poor / missing support for testing and things like staging / production environments

- Lack of support for 'metadata' - things like comments, commit messages, seeing who changed what and when, especially when multiple people get involved (this is maybe another way of saying 'version control')

- Pricing plans that make it very expensive when you cross certain usage thresholds or require certain features, or simply hard limits on usage that you run into and are hard to work around

- Vendor lock in and difficulty hiring/training people to maintain and extend the solutions.

All this is not to say that some of these tools don't have value, we still use some, but over time these limitations become greater relative to the benefits you see early on in terms of ease of use and speed getting something basic up and running.

There are incrementally useful, but the current crop will not disrupt the demand for senior engineers, especially at product-focused companies or high-scale companies. It may cause some disruption in line of business apps or demand for developers for internal applications. The thing is, CRMs have been taking over this space for over 2 decades already and many have companies have already adopted these tools. Products like Salesforce, Dynamics or ServiceNow are very popular at non-technical companies, and they can just hire a few people through the vendor's professional services if any deeper customization or support is needed.

I have deeply reviewed PowerApps, Mendix, Outsystems, Pega, and Budibase. Despite what the vendors promise, this is more evolutionally than a revolution. Most still have serious problems at scale, and model driven development proves to be quite difficult for almost everyone. It's just not clear what value this provides: a typical CRM or BPM stack is better for semi-techincal users; programming languages are better for truly custom applications.

I've used similar as a kid (Multimedia Fusion, Klik & Play).

One problem is that it's built on a few layers and those layers often have bugs and limitation. We'd be making games and realize... oh, there's an 10000 object limit. Or that the movement engine has some miscalculations under certain conditions. Or that it doesn't have syntax highlighting and becomes very tedious to build/debug things that involve over 10 variables, like a city population formula.

We'd end up building hacks, plugins, our own systems to make up for these drawbacks. One guy made a syntax highlighter to copy paste. Another plugged it into Lua, so we'd write code in Lua and some adapter to have it reflect in the game.

In my previous job, we considered hiring people to do Cordova development, or try RN/Flutter. The CTO decided to just go native because we didn't have a big budget and it would be cheaper to hire both Android and iOS instead of spending months on plugins.

Devs pry aren’t the best people to ask about this because they will think about the 100 edge cases that won’t be well handled by your “nocode” solution.

If you’ve identified a legit user pain and developing something that addresses that pain you’re on the right track. Put it in front of users, get feedback and iterate.

Depends who your target demographic is. If you’re going after developers then such designs can often cause more issues (eg version control, DR, etc) unless thought about very carefully.

However if your demographic is technical folk who aren’t developers, then these things can be a massive asset.

Based on my recent experience building a few business applications with one of the bigger no/low code platforms out there, I am not a huge fan. It is too limited for an experienced user but still not complex for non-developers to achieve anything meaningful

Developers aren't the typical market for no/low code. Devs can already write code, so you are marketing something that not only do they not need, but can both limit them and make them feel threatened.

No-code products are well established as a successful model. Don't listen to the haters. But you have to market it to tech-savvy non-coders. Your product needs to empower them beyond what they can do on their own without it. Few no-code products empower people who can code - it may speed things up, but ultimately it forces them into your structure which is limiting and frustrating.

I find it hard to evaluate "no code" as a monolith. In some cases, if you can't think like a programmer, the fact that your "code" doesn't look like "code" isn't going to help you. However, (having clicked through to your twitter), I am familiar with Courier, and agree it is brilliant[1][2].

[1] No affiliation

[2] I've built complex notifications systems myself and think Courier is a beautiful solution for coders and non coders alike.

Coming from the opposite end, getting non-coders to do even the slightest automation, is that almost no-one has the interest or ability, and those that do are already doing it.

They can do mouse clicking and typing words (often very well, they are not dumb) but everything is manual, as MS has trained them do.

Same with very good Excel users, who you think would have a leg up.

(source: dos, powershell, power automate, power automate desktop, autohotkey, many chrome plugins).

Learn to program. No Code almost always causes more problems than it solves, plus your not building any real skills.

I told a friend who's kid likes game design to make sure his kid is actually programing. Once you get past the first 6 months or so, things start to make sense. If you can write a C# class at 19, you'll be doing very very well on your 20s.

Low Code solutions don't teach you any real skills at the end of the day.

> Low Code solutions don't teach you any real skills at the end of the day.

Hard disagree. Solving business problems is a "real skill" regardless of whether you're spending a week writing custom code which has to be maintained or gluing services together over the course of a day. Developers who don't have low code tools in their toolbox are going to be less efficient than those who do. Not every problem is a nail.

So are you saying a random person can build apps with no code solutions.

That's the promise of No Code, the business analysts are now developers.

The promise of no-code isn't to replace developers, but to lower the bar to a point where you don't need a senior engineering rockstar to solve business problems. None of the low-code solutions I'm familiar with advertise themselves as a way to get rid of your developers. It's all about reducing the complexity you're responsible for and delivering solutions more quickly.

These tools have a very valuable place in organizations. Recently I needed to build something which would grab an attached audio file in an email and generate a speech to text transcript of the contents and reply to the email with that transcript. Yeah I could have written actual code to handle all of this, but I was able to get it fully functional using Power Apps in under an hour.

I despise having to call my app “no code”. But after two years I did. Most people call my app a no code for prototyping so I’m calling it No code, No graphic Design.

https://uidrafter.com

One fear is that there is a cliff somewhere. First it is easy going and then you make what seems to be a small change but it is difficult or impossible to accomplish with the no code tool.

That's the fear that you have to relieve.

I'm not a tech person and I don't know how to code so I've been exploring the no-code space. I've tried this Frontlyapp which is so cool and it's saving me a lot of time so far.

It just locks you in even more than normal programming does. This is a feature in some places like modding video games or making cookie cutter websites.

But for devs it can be a restricting middle man with no benefit.

No code is a great way to connect solutions together.

Many businesses don't need to reinvent the wheel and the more they can use off the shelf the better.

I see no code as chunks of solved problem Legos. It has it's place.

Its great till you have to something custom. Then you realize you have to rewrite your whole stack to grow further.

For managers its great because you can hire amebas to operate it, but the moment shit hits the fan you can do nothing beside opening a support ticket.

TL;DR good for small businesses that have very easy use-cases. Anything past that will hit a wall sooner or later.