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.
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.
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.
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.
- 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.
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.
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.
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"
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.
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.
If someone's career depends on them not understanding something, they won't.
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.
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.
- 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.
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.
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.
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.
However if your demographic is technical folk who aren’t developers, then these things can be a massive asset.
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.
[1] No affiliation
[2] I've built complex notifications systems myself and think Courier is a beautiful solution for coders and non coders alike.
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).
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.
That's the fear that you have to relieve.
But for devs it can be a restricting middle man with no benefit.
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.
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.