I work for a SaaS product that enables developers to build app-to-user notification systems with minimal code, which I think it genius. But we often get hit with the Twitter comments that absolutely despise no-code or low-code solutions.<p>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, when in fact the goal is just to improve the developer experience.
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.<p>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.<p>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.
In my experience, devs that have interacted with no code and had negative experiences tend to fall in a few categories:<p>1. Used it themselves and didn't move any faster because of having to learn a new way of thinking<p>2. Used it themselves and tried to do something that seemed reasonable to them but the no-code couldn't handle<p>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:<p>- 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?"<p>- 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."<p>- 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?"<p>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.
It depends on what no-code/low-code is used for.<p>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.<p>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.<p>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.<p>I'm working on a startup, <a href="https://www.airplane.dev/" rel="nofollow">https://www.airplane.dev/</a> 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:<p>- 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.<p>- 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.<p>- 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.<p>There are some slightly more technical concerns that I have too:<p>- 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.<p>- 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?<p>Democratizing technology is important and low-code will I'm certain help discover some excellent workflow improvements.<p>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.<p>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.<p>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.<p>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).<p>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.<p>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.<p>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.<p>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.
If you are marketing to the right audience, then ignore the fuzz. In my experience, most solutions aren't marketing to the correct audience.<p>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.<p>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.<p>If someone's career depends on them <i>not</i> understanding something, they won't.
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.<p>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).<p>In the end, I'll probably use Budibase because it's FOSS and it seems more like the needed framework than the others.<p>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.
I think the backlash is due to two things: the audience and the limitations no/low-code solutions often have.<p>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.<p>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.<p>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.<p>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:<p>- Lack of good versioning / source control<p>- Poor support for 'schema changes' / data migrations<p>- 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<p>- Poor / missing support for testing and things like staging / production environments<p>- 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')<p>- 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<p>- Vendor lock in and difficulty hiring/training people to maintain and extend the solutions.<p>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.<p>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).<p>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.<p>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.<p>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.<p>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.<p>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.<p>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].<p>[1] No affiliation<p>[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.<p>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.<p>Same with very good Excel users, who you think would have a leg up.<p>(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.<p>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.<p>Low Code solutions don't teach you any real skills at the end of the day.
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.<p><a href="https://uidrafter.com" rel="nofollow">https://uidrafter.com</a>
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.<p>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.<p>But for devs it can be a restricting middle man with no benefit.
No code is a great way to connect solutions together.<p>Many businesses don't need to reinvent the wheel and the more they can use off the shelf the better.<p>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.<p>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.<p>TL;DR good for small businesses that have very easy use-cases. Anything past that will hit a wall sooner or later.