Will low and no code tools ever truly disrupt tech development?
stackoverflow.blog
stackoverflow.blog
Code is really just a formalized expression of what you want. It happens to be used for very complex problems, because it's very good at solving complex problems. This in and of itself does not make code inherently complex.
NoCode is just attractive because it propagates the myth that you can do things without programmers, and programmers are expensive. So you've got low friction + perceived lower cost == more users signing up.
Who cares? When I'm writing toy command line apps, complexity is never going to be the problem, certainly not in the 'what do I print to the terminal' part of the code. And if I'm writing actual software where complexity is actually an issue, the odds that this code has any business writing directly to standard out in the first place are infinitesemal. Your language is optimized to do stuff I'm never going to care about. How silly.
However, perhaps it's not _just_ about the short sightedness of inexperienced devs who get tricked into thinking a language is all that because of optimisations to the 'write some toy stuff' process flow.
Think about it, how would you write a tutorial or 'sales pitch' for a dev environment/programming language _without_ focussing on how easy it is to write Hello World and other toy projects?
How would you highlight how the namespacing system seems like overkill for an app whose entire codebase is half a page of text in a large font, but is actually really good at making an easily navigable codebase once we hit the 5 personyears level? I really have no idea how you would show it. You could talk about it and pray that the reader is familiar enough with the challenges of codebases that have grown beyond 'one person tinkering around for a weekend', but almost by definition I don't think you can bash that down into a tutorial or pitch you can consume in 5 hours, let alone 10 minutes.
Still, languages could do more. I think most languages are just kinda bad at natively supporting the idea of DAG-based modular isolation: As code bases grow larger you want to be able to strictly enforce the ability to take a much smaller chunk of that base, draw a circle around it, and say: This can be understood on its own, it is dependent only on these things, and only these parts are 'public API', 'public' here meaning: accessible to other circled-off parts of the entire code base.
Maybe because it demos bad. And that's a real shame. It's many orders of magnitude more important than 'You can just write `puts` to echo to terminal, and there is no need to declare a method for the main entrypoint!'
It could even be a relatively fake example and I think it would still land if your audience has had experience exploring large codebases
The problem is this can get pervaded quickly.
In most extreme cases, the 'example' is literally only useful for hello-world style things, and anything more complex requires digging deep into docs to understand (I can think of at least one .NET library where this 'blogger-friendly' API structure exists...) And then as alluded to, every example shows this simple case that doesn't help anyone know how to configure things in ways that are testable/etc.
I don't think it's a good idea (in a disruptive-amount of cases) to deviate from the simplicity of straight forward code.
We are growing closer and eventually will realize as a society that programming doesn't have to be hard or scary. I'm sure that the futuristic lay-person will have a better basal understanding of technology and how it's made.
elements
shape Wrapper
text Label
style Wrapper
fill: blue
style Label
content: Click Me
fill: white
I feel like we actively discourage people from having an understanding of technology for fear that they will understand it and complain about it and/or be in a better position to judge the quality of alternatives to our products. As a result, it seems like more people understood basic computer operation and architecture 30 years ago than they do today, but maybe I'm in a weird bubble. I'd think with the opportunities for the far more opaque operations and algorithms that deep learning has given us, people will understand even less about computers in the future.
That being said, we've always built knowledge on top of the backs of others and never really had to deal with supporting its weight without necessarily knowing the basics. It would really make for an interesting case study if it led to the collapse of society.
I don't think it's this, and I don't think programming is so hard (it's the business logic that is hard when you have to specify it exactingly, to reference the thread.) I think that the manufacturers of the various computers we use make it unbelievably difficult and scary to touch anything, and cast quite a bit of suspicion on you for even wanting to change anything.
I think the idiot-proofing of modern computing is only making people less aware of how computers work. Think of how many 20-something programmers got into programming from learning how to make Minecraft mods. Or even just learning to install a mod in the old Java version of Minecraft or any other PC game, where you had to dig into weirdly-named folders, copy-paste files into various directories, maybe modify a data file here and there. Kids growing up on the iPhone version of Minecraft are never being exposed to the basics of how their device works.
https://www.theverge.com/22684730/students-file-folder-direc...
Those kids are generally more ignorant of how software systems work than someone who grew in the 2000s.
We now have a "digital native" generation coming of age for whom the only thing they have known is a ubiquitous internet. We might expect that they would be more intimately familiar with the workings of the technology that has surrounded them than we could ever be.
Yet the opposite seems true, and I think you've put your finger on a primary reason — they've only interacted with devices that are basically appliances — you turn it on and use the app, but it is very difficult to get inside either the hardware or software. So, it just becomes another box that either works or doesn't.
It is not dissimilar to the generations of people who grew up with automobiles. the more "user friendly" they technology gets, the fewer people even understand what goes on 'under the hood'. If you don't need to understand how to change a tire or change the oil, or check the valve backlash, because these are rare events, few people even have a clue how to do it, unless someone took a special effort to teach them and they took a special effort to learn.
Kind of a sad paradox.
Honestly: if you come to such a (dubious) conclusion, the conclusion is actually likely true (with respect to you), because if you were smarter, you would sooner or later realize the mistake in this flow of thoughts.
If you want to become smarter in math: Plan to understand work that some Fields medalists of your choice produced. If available, get a modern textbook treatment of their work (these, in most cases, are better for understandable than their original papers). Of course, you won't understand much at the beginning. So you know in what areas on mathematics you have deep knowledge deficits. So get some good textbooks on these topics to fill these knowledge deficits. Iterate.
-
If you want to become smarter in physics (the following advice is what a good friend of me gave who I really trust regarding this): Start with the 10 books of "Course of Theoretical Physics" by Lev Landau and Evgeny Lifshitz.
> https://en.wikipedia.org/wiki/Course_of_Theoretical_Physics
Having read these books should (according to him) give you at least some very basic foundation of physics on which you can then, as a next step, build by reading much more advanced textbooks.
You realized where the mistake in your flow of thoughts is. This is, as I wrote, a good sign.
Besides the obvious UI issues (like the fact that you couldn't really zoom out, you could just pan around your code), we had a bunch of engineers that still needed to do things like "get the three largest values from this array" and it just turned into the most ridiculous bubble-sort implementation you've ever seen.
Its pretty hilarious seeing some of the old screenshots now [1].
Anyways, I think it will always be really easy to sell some simple demos on low-code/no-code, but then the second you need something slightly outside the eco-system it just turns into a substandard mess that doesn't work well with source-control (or diffs) and in general is just harder than the code-full solution.
Also, I want to agree, but algorithm code can look ridiculous in any language, graphical or not.
I think graphical coding and "real" coding will merge from both ends. An advanced IDE today is already sort of beginning to look graphical.
Disclaimer: I work for Zapier.
Great example of where low-code is a better alternative for a very narrow use case of development.
We also had a ton of horrendous LabView spaghetti which was even worse.
- Logic tends to take up a lot more screen space than real code
- There is no defined way to read the code. In real code you start top left and read left to right and down, but in visual code if there are lots of "paths" then your eyes end up darting around everywhere.
Control systems have always been designed in a connected box fashion. Before gui software existed. Visual coding is just an extension of what was being done on a blackboard
> Maybe designing models is better than writing low level code for control algorithms?
If you need both the code and the model, then generating the code from the model is also much easier than proving that your handwritten C code behaves exactly like the model used for verification. Having visual control flow for complex control systems might be less error prone than manually writing C (or Rust or Zig or $flavour_of_the_day) code. You probably know that, but other folks shouldn't forget that automotive and aerospace control software often means "programming errors might result in people getting injured or worse".
Vcs integration and merge were also a big pain so most of the development was done on a single computer in the lab by many people.
The hardware that runs the LabVIEW code is solid tho and once you wrestle LabVIEW into doing what you want it works well
One of the core errors of the most breathless low-/no-code advocacy is that they clearly see that code as it stands today is very complicated, but they think it's all accidental complexity. If we just did the right things... if we just made it easy enough... if we just had the right visual user interface... all this complexity could go away! And then anyone could code! And lo, Utopia would emerge.
There is a grain of truth in this. Code does have accidental and unnecessary complexity. Some traditions and codebases have more, some have less. The low-/no-code approaches can help with this... though I have to qualify it a bit because at times they add their own accidental complexity to problems that traditional approaches don't. But they can be easier sometimes, certainly.
The problem is that even a hypothetically perfect low-/no-code solution with absolutely zero accidental complexity still wouldn't do anything to eliminate the essential complexity of the problems people want solved. I don't care how amazing your no-code UI is. I don't care how visual it is, and how you can grab any 12-year-old off the street and show them your UI and they can grasp everything that's going on. I don't care how much work you put into it. If someone tries to use it to create a tax preparation service, they are going to ram face first into the brick wall of the essential complexity of the problem.
No matter what you do, there are going to be people in the future who have developed a skill set in dealing with that sort of thing, and it isn't going to be a skillset everyone develops to the same degree. Even if you stipulate a domain expert who knows literally everything about the tax code, it will still be a distinct skill to learn how to explain that correctly to a computer, even a zero-accidental-complexity computer.
It is further inevitable that the people dedicated to that will have their own toolset that tunes the expertise and power level to the fact that they are able to pour more time into developing skills that have a longer-term payoff than people who are "programming" for six hours a year.
It is literally impossible for low-/no-code to take over. Even if I pushed a magic button that replaced everything in the world with low-/no-code solutions right now, the world would still bifurcate into the people who further develop their skills with the system, learn how to use it efficiently and effectively, and people who do other things like build houses, provide clean water, etc. The only way to make it so there is no such thing as a "programmer" is to forcibly cap the capability of the universal low-/no-code system so low that there is no way to become better at it, which is just inconceivable.
Some stack that avoids all that complexity would be technically "low-code". But the format of the low-code stacks people push around today is incompatible with general development, and doesn't actually make most of the complexity go away.
I started my career at a company that sold a graphical programming product. It's exactly the typical "no code" thing described elsewhere. Nodes and edges to implement Ifs, Loops, actions, subroutine calls, etc.
We sold this to customers but also had an in house professional services type department that used it. Those folks were indeed at a whole nother level with that tool and knew all kinds of tricks and had developed special scripts to transform the XML formatted files that the "programs" were saved in, etc. They had developed a long slew of best practices to try to tame some of the problems of the tool.
Then someone added a "execute arbitrary javascript" action and it was open season on everything...
I think when I left someone was working on a linter!
So it might be that node based programming is a good way to allow non-devs to interact with parts of an otherwise code based solution, inside niches. Examples that come to mind are eCommerce shopping rules. They can be complex, and really arbitrary, and in many ways having a developer implement them is really inefficient. Giving a node based pipeline editor for shopping cart rules would be a boon for power-users and take time off the dev's hands to focus on implementing the surrounding ecommerce solution, something you definitely don't want to be writing in a graphical editor.
The more narrow the domain, the easier it gets to figure out a low-/no-code environment that will work for the users. But the smaller the base of purchases. And distilling the complexity to just the right level still takes some really bright domain experts with extremely good intuition of where the most profitable use cases lay (the hardest role to fill) and highly empathetic coders (also hard to fill) who work well together (extremely rare), or a single person who embodies both (unicorn).
If energy and money were no object, low-/no-code is absolutely A Thing. I believe there is some kind of emergent Shannon–Hartley theorem behavior here, where complexity down a communications network with certain noise/bandwidth/etc. properties has some suspected hard physics-as-we-know-it limits.
I actually pointed out in the training that this is still coding - at least at a scripting level - with all the pitfalls that involves. Nobody there really understood, and some actively tried to deny this point of view (I thought that was a bit weird and culty, but there you go).
One problem is that if you, as J Random HR Employee, implement something with a bug in it (which you will do at some point), you may not be well equipped to diagnose and fix the issue. It's not that hard, not at this level, but the training sort of glossed over that.
And then I asked a question about the fact that all these services that were being integrated together were distributed, so what happens when something fails part way through a flow? What happens with consistency across the different systems you're integrating? Well... it depends on the adapter for each specific integration, but in most cases you're supposed to implement failure handling yourself.
In fairness they showed us an example with failure handling and enforcement of consistency for something that integrated perhaps half a dozen systems together... and it looked pretty complex, just as you'd expect it to.
And that's where I think these things fall down. You can build a happy path flow pretty quickly - in fact I suspect a lot of non-programmers could do that - but it's what happens when things go wrong where it gets really gnarly.
Basically, if something goes wrong either IT or DevOps are getting a call, or somebody in a business, HR, or finance function is manually logging into a bunch of systems to update them and bring them into a consistent state.
I don't think this is terrible necessarily, but I do think the capabilities of these low/no code solutions - particularly with respect to their use by non-techies - are way oversold.
It's same reason why design starts on napkins, then wireframes, and then low def, high def and eventually a fully interactive prototype.
In software we dive into code way to eagerly and way too early in the product process.
Equating no/low code tools to full on dev is impossible. Just as you wouldn't/shouldn't equate a design prototype to napkin scribbles.
Low code doesn't help at all? It's still code.
> Low code allows "less" sunken cost when the inevitable misalignment of requirements happen.
Sunken cost is about investment already incurred that can't be recovered. It's very likely that low code increases software sunk cost problems.
If you use low code as a prototype thing to throw away, that's almost a complete waste of investment.
Wrong low code often is much harder to programmatically test for correctness and debug, so you often need a larger investment to fix it.
I see the exact same thing with code: the complexity is eventually abstracted away until it becomes a vocation that doesn't require a college degree (think mechanical engineer vs mechanic, computer scientist vs programmer).
I see the low-code stuff as an opportunity to let the business-folks handle the usecases where the complexity is low, and value of rapid iteration with deep domain-knowledge is more valuable.
Also, they might get a better understanding of why the code stuff might make sense when stuff is actually getting complicated :)
Most cars have automatic transmissions now. Cars don't have manual chokes anymore. They're reliable enough now that most people don't need to know anything about repair, engine or otherwise, whereas that used to be widespread knowledge.
I get your point. But without low/no-code tools I would argue a lot of simple workflows have to be implemented using code. These usecases, where the technology-side is simple, is a good fit for low/no-code platforms IMO
I've seen teams spend a lot of time in low/no-code tools and either it grows more complex than actual code or they resort to the escape hatch (node that executes user defined code) and the visual tool basically becomes a container for actual code.
Also, the dream usually is put the effectiveness of software developers into the hands of people who are not software developers. However, it never seems to fail that the low/no-code work ends up back in the lap of software developers because of the typical product/project delivery lifecycle.
The ideal state alluded to is that Dev teams write modules that cleanly 'plug in' to the flowchart mess, but the reality is that a Dev team that can write code at that level (in a modern world, it implies at least an abstract/subconscious understanding of mid-advanced FP-ish concepts, including merging Procedural things like calling the bizarre webservice you're probably integrating with, while striving for idempotency based on the provided args/context.)
At that point, said devs likely are of a skillset they could build a framework for lower TCO, or at the very least are productive enough that they aren't the problem.
whether you think it's complex or not, we're hiding information on procedural tasks from users in the products we build because information to someone who is not a programmer IS complex
What they meant was "the end of on-prem software and its installation headaches" because the software was in the cloud - which was innovative at the time.
What appeals to people in "The End of Code" is the end of being forced to use a superficially illegible formal language.
A perfect equivalence is if you were to do math exercises but instead of operators you used written English prose to describe what you are doing.
Much less intimidating, but mind blowingly verbose
At the same time, on a deeper level there are things that can be hard to deal with like asynchrony, performance, etc. These are not social but inherent in computing architecture etc.
The problem these days is everyone wants great software (big tech impostor syndrome) without splurging on software talent like big tech. That’s the sweet spot low code companies target when marketing.
Graphical coding is bad in general. It’s not just paid products. I’ve had the misfortune of using Apache NiFi - which is “low code data movement”.
If you think it will make things easier you have confused typing to be "the hard part"
If you think it isn't real programming, you again have confused typing to be "the hard part"
For example, Javascript's stdlib has long lacked tools for simple data transformations (group array items by a function, transform values of an object by a function, etc). These operations can still be accomplished, but only by writing bug-prone manual transformations or using third-party packages like Lodash. There is no standard idiom for expressing these ideas, which causes significant overhead.
No-code/low-code, in contrast to general purpose languages, is savagely optimized for idiomatic expression of a small set of ideas, at the expense of the ability to express any arbitrary idea.
You CANNOT solve complexity by just making things "visual". Biggest low/no-code mistake.
One of the biggest benefits is the sense of excitement this creates for these users as they are able to add the logic of programming into a process that was formerly a manual one. When they do reach their "edge" around low-code, they can then engage development teams with better knowledge about the system and a clearer vision for what they need.
As other comments have said, low-code will always have trouble solving special cases due to their very nature of being simple and interchangeable. However, empowering others to solve these low hanging fruit problems liberates the develops from a backlog full of basic functionality and allows them to focus on the big problems that will require more robust tooling and design.
At the same time, I've also seen users do incredibly crazy things because either they didn't know any better or just didn't bother to "read the code". Good example of this is people just keep creating Statuses in JIRA until you end up with "Which of these 264 'Completed' statuses is the one I want?". It's similar to the Ops person "Hey, I wrote a Perl script that does what I want. Yay!" that turns out to be a spaghetti ball of copy/pasta.
This is maybe less of a point about programming and more about governance. Either way, you will still need specialized people who make sure that everything is being done in some kind of guardrails.
Why is this a problem? Programs are a means to an end. The 264 Jira statuses are messy and could be done away with, but would a clean solution actually change anything for the better? In a significant, "it was worth spending the money on a real developer" way?
"Let's not waste money on a programmer so instead everyone in the company wastes millions of man-hours every month slowly filling things the wrong way!"
There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough.
- The Art of Unix Programming
This is because a lot of so-called "real developers" nowadays think their job is to keep up with the latest fads and finding ways of chopping the business needs in a way so they fit better to the popular framework of the day.
Business quickly grow tired of hearing "that's not possible" when what the developer actually means "what you want to do is against the architecture of the framework I've decided we must use". If the business insist, the developer spends a lot of time fighting the framework.
Now, from a job market perspective, it is entirely understandable that the developer prefers to do RDD - resume driven development.
But it also makes it fully understandable that the business people wants to find ways of solving their needs, that do not include waiting on the "real developers". Hence the Excel and Access monstrosities present in every org.
I agree with this.
There is a hidden market that exists between "Developers" and "End Users".
With Pure Data, I found this in the games and interactive audio industry where much of the procedural sound we made was done by "artists" essentially. Rapid prototyping using visual languages gave "good enough" code that could be exported to C/C++ later for embedding.
Again I saw that with LabView in industrial modelling, where engineers who are not at all "expert" coders could work within their domain of expertise and spit out code (also through tools like Matlab/Octave and NetLogo) as basically a very advanced (demonstrably working) "requirements spec" to any developer who wanted to take it further.
The win comes when you realise the lifetime of many rapid prototypes is good enough, and real developers are expensive enough, that the no-code "mock-up" is the actual product.
It happened with a job I did for the British Foreign and Commonwealth Office, when I showed the POC that took a few hours to knock together and they said, that's good enough, just put that demo into production as is. The scope was only a 7 day campaign.
I see no-code as a peoples' config language that should basically replace the interface of devices like Android. Kids as young as 6 can understand stick and box dataflow diagrams. When "The diagram is the program", configuring things like privacy settings or app preferences might better be done in this domain.
That doesn't make developers who use real languages obsolete.
A good model in my mind is Excel. The amazing part of Excel is that it can be used as a no-code tool, a low code tool, and extended with code macros. Even self-described non-coders who would otherwise be intimidated often use to extreme productivity. It's extremely visual, straightforward, and self-contained for the most part. The fact that it's so well documented as well is also hugely important. The no code solutions I've seen and worked with usually are fairly lacking in this regard, but excel has fairly clear documentation, the famous f1 key, and a support line[^1] which makes it a more default choice. The only problem is that integrating it with your other tools relies on either 3rd party plugins, a coder, or integrating specifically w/ other ms software.
[^1]: I had a professor state in a comparison between MATLAB and Python that the reason to choose MATLAB was that they had a customer support line. This wasn't a CS professor, so you shouldn't underestimate how much value is placed on talking to a human rather than RTFM by non-coders.
And this is the rub with low/no-code solutions. To use them effectively, you have to have some programming skills already.
They are perfect for lazy programmers, but less so for "Citizen Developers". At least, I haven't come across any I was really impressed with as a "Citizen Developer" platform. I would happily take references to any I should check out that might succeed at enabling non-coders to build production solutions.
If you were trying to write a simple Python program, you'd need to know how to run it in the first place. This means you'd need to install Python (if you're on Windows then you need to add it to PATH which an entirely new issue). Then to edit the program you need an editor (thankfully Jupyter has made this a lot more trivial). If you want to do anything outside the standard library, you need to learn to use pip (hell you need to know what is considered standard and what's outside of that scope in the first place). Coding to me seems to some extent to be more than writing logic, but also experience with programming environments. Low-code solutions seem to be just a lower on-ramp. You still have the logic, but everything is self contained so you don't need the environmental experience. You're therefore limited by whatever is provided in that self-contained environment.
So while I may not have met enough people to really say, a lot more people can "code" than can write programs in the sense that they fundamentally can abstract the necessary logic, but are intimidated by the unfamiliar work flow. Citizen developers can be born from this demographic of people, but the problem is that the tools available are often too limited to stick with and don't allow for production solutions.
> in my experience the target consumers for no-code/low-code aren't the people completely intimidated by computers or navigating software in the first place.
These tools are definitely not for them, I agree.
> Low-code solutions seem to be just a lower on-ramp.
Agree.
> a lot more people can "code" than can write programs in the sense that they fundamentally can abstract the necessary logic, but are intimidated by the unfamiliar work flow.
Not quite sure what you're getting at here. But - the way people talk about "Citizen Developers" is, it's the people who know the business logic really well, they know their tools really well also. Spreadsheets, web forms, even some databases perhaps. But not "coders" per se.
So you start with a person like this. They want to automate something using a no-code solution. Sooner or later, they're going to have to parse some input file, hopefully something structured like JSON or XML. They have to learn about parsing such files, which is by any measure a programming skill, even if they're using a no-code tool for it. They need to learn the principles of it to make it work for them. And thus:
> Citizen developers can be born from this demographic of people
At that point you're training a developer.
> the problem is that the tools available are often too limited to stick with and don't allow for production solutions.
This is also my experience. But if we imagine evolving all those tools out there to be production reliable, and flexible enough for whatever task... You still have to take on the journey of training a non-programmer to be a programmer of some stripe. You don't end up with the dream of non-programmers intuitively building production apps out of thin air.
Visual Basic I believe was born from the same idea, of making more intuitive tools so people could focus on the business logic, and less the fiddly bits of coding. But make no mistake, Visual Basic produced programmers, and not business people who built apps.
>At that point you're training a developer.
I don't think this is necessarily the case, or even if it is, I see this as not a problem and even a perfectly acceptable situation. The goal overall is simply to take someone who wasn't originally hired to code, or someone w/ institutional knowledge but no traditional background in programming and empower/enable them to build production applications or tools. Whether in doing so they learn to write code or not is not really an issue one way or the other.
>They are perfect for lazy programmers, but less so for "Citizen Developers".
This was in your original comment and to what I was mostly responding. It seems to me that low-code solutions like Excel do indeed enable people who don't consider themselves programmers to build tools. To a certain extent no-code/low-code solutions like Squarespace do a similar thing, where someone without ever knowing what HTML or CSS is can still build a website, but obviously someone with additional experience would be able to make even better use of the tool. Basically my issue is that I think low-code solutions can actually be pretty decent and useful, but there are a lot of bad solutions out there and I obviously don't see them displacing coders. However, I wouldn't go as far to say that you need to train someone to program in order to make use of low-code solutions.
But we will continue to see domain-specific tooling that require less "coding". There are plenty of "no/low code" CRUD app builders, tools that manipulate components on a canvas to create web pages, even tools to integrate different systems together. But the second you need to go off the trail, you've now got a big problem: you're constrained to doing things that don't break the no/low code environment, and that's a lot harder than rolling your own components and customizations.
Anything interesting enough to "disrupt" tech development will, almost by definition, not be possible in a no/low code environment.
100% agreed
Came up in another thread recently but Unreal Blueprints is a good example of that https://docs.unrealengine.com/5.0/en-US/blueprints-visual-sc...
It's robust and perfectly fine, you can even build full games without any coding at all.
Is it useful? Yes, but it would never replace "real" coding. Yet I'm excited to see any advancement on the field because it still feels like "magic" to some extent.
It does raise the question where the line is. Something that I'd consider a low code / no code platform is webflow. My non programmer CEO used it to create our marketing website, and it solved something for us that normally is a very highly technical problem. He had a couple small visual glitches, he asked me to help and I discovered that it actually was a pretty thin abstraction layer over some good practice CSS, and so the glitches were easily fixed by me thanks to that.
Blueprint makes a programming language easy enough to use that a non experienced programmer might have a go at it, but in the end it's really just the outstanding library that makes it so powerful, you still need programming skills to solve programming problems with it.
Maybe that's the line is? You can create applications but you won't be able to debug once you run into a problem/bug
Back-end feels really risky to me, because visual logic builders are just so limiting compared to code.
That obviously isn't viable for all early businesses and even the ones it is viable for eventually need to hire engineering teams to build their products, but I love how much more accessible these tools have made shipping something basic.
Of course, this is a bit different for low-code tools that are used internally etc.
This might not be an issue for SaaS who already publish their source code but for the vast majority of no-code/low code, it seems to cater to small to medium enterprises who are constantly looking to reduce their cost centers, even after achieving it an optimal setup.
I am pushing Bubble to its limits where I have access to approx 150m records with all sorts of other database relationships to many millions of records.
To build this app in a custom software solution, I have been quoted $100k to $500k depending on the backend architecture.
Instead, I am spending around $20-30k in development costs to get my app off the ground to be able to pick up the first paying users... at least that's the goal and I'm a few weeks away from launch.
I would also say that my "MVP" is not like Airbnb's MVP... my hope (and it seems) that it may be functional enough to nearly (70%) replace my existing CRM that I use day to day. Of course, I am planning to transition to a custom software solution once I validate, so I don't see bubble as a long term solution.
I've self taught myself a bit of python and tried teaching myself JS as well off and on, so I am able to generally talk through with software developers what I'm trying to achieve and generally understand the technical things that might be discussed. So I'm not entirely a total non-technical noob.
But the issue with Bubble is there is still a high barrier to actually learning how to use the platform for the average non tech person. It's a black box of sorts and they don't have the best education (unlike webflow). I mean come on, you have to pay $800 to take a bubble sponsored course? Lame. Nonetheless, you learn programming concepts by learning how to build on bubble.
I'll end by replying to the top comment about code being perceived as complex.
Spanish isn't complex. Nor is French. Maybe we can consider Japanese to be more complex. But even then, millions of people speak it just fine. Conjugations in Spanish are complex for a 40 year old English speaker new to Spanish but not complex for a 8 year old native speaker.
But after a certain age, life takes hold, you begin working, and you lose the time and opportunity to spend 100's or 1,000's of hours learning another language. Trying to learn how to code is like this. I sometimes need to carve out 3-6 hours of a day to context-switch away from my busy (non-technical) professional & social life to get back into programming mode.
Low code tools abstract away hours of that complexity you would have to learn, which allows you to start building something functional quicker than you otherwise would have. I know software devs look at low code and say "what's the matter with this crap, I can just spin up a X to do Y in 1 week, this is worthless!". But you are the native Spanish speaker in my metaphor, not the folks learning Spanish way past the days they had time to learn Spanish in college, trying to build the next greatest Spanish hit song to tell their story (i.e. software app!)
To probably strain the metaphor, native Spanish speakers see this like you're struggling with Spanish so you give up and instead decide to learn Esperanto because it's easier and a few people have sold it as being a good alternative to communicate across cultures. You run off and spend 4 months on Esperanto and have a song written and a catchy tune that is well received, but when the time comes to publish an album for the Spanish speaking world, maybe you've got some notoriety built but you've still got to start over from scratch and learn Spanish. For most people, they aren't going to make a hit song on their first try, they're going to fail and have to try again, so learning those Spanish fundamentals instead of a shortcut might have been a better use of time.
As someone without a lot of budget to hire devs, I currently use no code in my company extensively, our Airtable has 50 tables, some of them with > 10k records.
There is certain excitement to do all in no-code now, but the ceiling is truly there as the article says, the rule of thumb is that if something is operational and not core for business we do in low code, if it is business critical (we lose money if goes down) then it gets coded.
What happens if our business goes down, and is <low code tool> fault? We can't just say "welp" to our customers complaints, recently we saw that not even Atlassian is immune to long outages.
Also what happens when the market needs for you to do "X" and the tool can't? Now you are stuck in a low-code environment with 3 months migration while the competitors pass ahead. We also got a lot of bugs with this tools on things that were supposed to work, and it slowed us down significantly.
From what I see that the best use case of low code is kickstarting software projects. If done with the right tool (one that allows for easy exporting), it allows to get the data in order for future scaling with code.
Since changing application logic in a living project (and even the entire language / framework) happens all the time, but the data generally does not, this seems like a best case scenario for a new feature or product that still needs to validate their market fit.
But niche applications or parts of applications might be. We see lots of “apps” that are spreadsheets or old access databases. In games/vfx and sound you see “shader graphs” and “audio pipelines” take over the job of code for parts of a codebase.
Learning tools with puzzle pieces for code statements aren’t “low code” they are just an accessible way of writing regular code. The amount of code created is typically much larger and the complexity higher than with a regular language.
Regular program code is the low complexity answer to general purpose software development.
But as an "aid" to empower developers... absolutely.
The lowest hanging fruit for a low-code solution would be in the Front-End space since you're dealing with a visual medium anyway, and because Front-End work isn't "hard" as much as it's super tedious which is generally a good target for disruptive automation.
Of course one of the big challenges will be that devs are most comfortable coding in text-heavy non-GUI environments like the IDE or terminal, and any low-code tooling that leans on a visual interface is going to struggle.
This was actually a huge problem for me at https://rapidream.com (apologies for the shameless plug). I wanted a Figma-to-React dev-tool that I could actually use on my real "day-job" projects, but designing an interface and user flow for users who don't like low-codey tooling was almost a bigger challenge then the actual tech.
I think the take that frontend isn't hard is extremely outdated. Responsiveness and a11y are nuanced problems with huge surface areas. As designs get more complex, keeping all these things in check requires tooling that needs to be learned. People on HN constantly bemoan the complexity of frontend development and how hard it has become. There's a reason drag and drop isn't the default way of creating a web page, despite tools for this being around for 30 years.
It's not Front-End dev as a whole, just the "pushing-pixels" stuff.
There's a ton of difficult FE work (esp. state). It's just that when it comes to a lot of the "basic" styling and responsiveness there's a lot of tedious work that should be automate-able (just like any framework or library, the goal is to reduce unnecessary work, not to suggest that the work is trivial).
Switched-on developers are a perfect market for good no-code/low-code tools. If a tool is 100 times more productive, why on earth would a smart developer not use it to deliver value to their customers??
I wrote a complete ERP and CRM system using our No-code platform - this would have been impossible for a single person using traditional tools such as Java. I've written a couple of blog posts explaining why the rise of No-Code/Low code is inevitable.
https://www.onedb.online/blog/why_no_code_is_better_than_ful...
https://www.onedb.online/blog/the_future_for_software_engine...
I don't think so?
The problem we should be solving is not the accessibility of code itself, but the accessibility of toolchains.
The most confusing thing about learning to make software isn't writing a Hello World program or a Fibonacci series loop. It's figuring out what to do with that code once it's written.
People don't interact with terminals and shells anymore, but guess what nearly every Hello World program is written for? A shell.
We have a lot of tools that try to hide the toolchain, and even the shell itself, from the uninitiated developer.
Unfortunately, hiding the complexity of the very system you are writing code for causes more problems than it solves.
How can you learn to get input from the user if you don't even know how to use a shell? How can you start using libraries if you don't know where they are, or how they are distributed to the user? How do you configure the correct environment variables if you don't even know what shell you are running or how/where it was initialized?
We should instead be doing the inverse: do everything we can to show new programmers the system they are using. Show them all the pieces of the puzzle, and how those pieces fit together, because our new programmer's primary goal is to make new puzzle pieces.
Building the same thing from scratch would have taken me two weeks or so.
I am saying this as someone whose main job is providing a CMS, so I am familiar with having to create a simple enough interface for non-technical users to use my CMS.
Hats off to Bubble.io for achieving such a usable interface for being able to knock up an app this quickly.
At the same time it is clear that some actions which would be painfully simple to perform in code take a lot of clever thinking and hacks to convince bubble.io to do it.
It also won't scale and if it breaks for no reason, it'll be nearly impossible to fix it.
If it doesn't provide a certain bit of functionality, you have to add your own CSS / JS and that's where it becomes clear that my extensive knowledge in web development contributed to my ability to use this no-code tool a lot.
Ultimately, I think a no-code tool can be a great way to enable programmers to build things quickly, but I think the ability to think like a programmer is still worth learning.
I'd be surprised if these tools could replace anyone building complex applications in the near future.
Even "control panels," require a lot of training, for complex enough machinery.
However, a great place to see well-written PHP, is inside the WordPress stack.
I'm not a front end guy, but I was able to write exactly what I wanted directly in HTML/CSS in around 2-3 hours. That's for a static site with responsive layout and like 3 pages.
Could someone who is actually in expert in Wordpress's editor do this in less than 3 hours? No doubt. But at the end of the day, all it cost me to build a vastly superior solution was a few hours (and again, I'm not an expert at frontend stuff at all, so that was not as fast as it could be done). Instead of having to host a bloated Wordpress site now, I just need to serve a few static HTML/CSS files, which can be done for free nowadays with a lot of providers.
So the no code solution is more expensive to operate, and less efficient/performant. But at the same time, it doesn't require an expensive developer (even if an actual front-end dev would only need 1 billable hour at most)
The ability to assemble 60%, 80%, even 100% of a simple application by snapping together building blocks has lead to a massive democraticratization of programming. Yes, and buggy crap and security holes, but it’s easier to fix some of them by improving the Lego bricks. This is a triumph of abstraction.
==
The first “no code” system I ever saw was called, IIRC, “eve” at some PC expo back around 1981. There was a bit of buzz in the press and then that was the end of it. Then again, that was the promise of FORTRAN (and then COBOL).
BTW the article itself was meandering and mushy. I gave up on it.
Instead of hiring developers to do a 2-month project to build us a suite of admin tools, I built them myself in Retool over the course of a couple of days.
For a non-developer, maybe we're still far away from disruption. Excel seems to be the programming platform of choice for most people anyway.
But for developers, these things turn you into RoboCop. It's amazing how much I can get done now that I don't have to worry about UI, build pipelines, etc.
Honestly the hardest part of my work with Retool has been convincing other devs that they should use it for internal use cases. While they’re still waiting on designs to be done in Figma I’ve got multiple users trying out a solution in Retool that I can update in near real-time to see what works best.
It's such a great combo.
I'd like to present a specific use case as an example of how domain-specific no-code tools can help.
I'm developing a tool for automated browser testing. This fits well into the description of being no-code and is being developed as an alternative to writing C#- or Java-based browser automation tests in Selenium.
The "code" that you write is more akin to configuration that defines what page elements you want to interact with, how you want to interact with them and what you expect to happen. There's more to it than that, but this is not a sales pitch.
My project is in direct response to the experiences my partner encountered when providing browser automation training to manual testers within businesses.
Browser automation testing requires, in broad terms, a small subset of what is offered by C# or Java, however a significant understanding of and familiarity with matters such as objects, variables, sane naming and debugging is required to even begin reaching competence.
Many manual web testers, who were very capable, were just not able to grasp coding matters sufficiently. Many were, but plenty were not. For those that barely could, I feel for the people who have to maintain what would then have been created in their businesses.
Programming that requires only a subset of a general-purpose programming language has the capacity of being implemented in a no-code tool if the scope of the programming needs are narrow.
From 1998 to 2004 I worked as the IT manager at a plastics manufacturer whose entire system was backed by SQL Server, and fronted by MS Access databases that people ran locally for the forms and reports (no data was stored in them) or Excel (same thing). This is low-code in a nutshell and it worked well back then: it was CRUD before websites were CRUD. And we were constantly developing it and building out more complex scenarios for industrial production control and accounting and reporting.
Why? Because it worked, it allowed users to conceive of the next thing they could use, which inevitably led out of low-code scenarios. At one point we seriously investigated hiring trying to implement bin-packing algorithms in VBA so that warehouse pickers had better direction in order assembly.
Low code systems either don’t work, or they do and create demand for “high code” solutions.
But this and other examples don't feel like disruption though because there's still an ever expanding universe of work that requires code.
I just replaced an internal web app used for planning with a data visualization tool dashboard that can spit out a spreadsheet for further analysis. Took a week to build something that solves the business problem better than several months of effort put into the web app did. I didn’t have to deal with auth, security and privacy reviews, building a custom UI that people would have to learn, learning data source API’s, or build/deployment.
The category of people who are ready to invest time in understanding those tools are the people who might as well spend the same time or less learning SQL and maybe a bit of python or VBA.
As for business users doing code, I wish there were more, and I think younger users tend to be a bit more technical, but it's a light breeze, not a big change.
I do a lot of work in geometric tools, and the fact that the best thing that we have for unit tests is to painstakingly construct objects by specifying their coordinate space hurts. Our team gained a lot of velocity on building and maintaining unit tests by simply writing a tiny graphical tool to convert back and forth between a text representation of a coordinate space and a visual representation, because visual presentation is far better for the average human than a text description for a bunch of circles and rectangles. The signal gets lost in the noise.
I also still think there's meat on the bones of tooling that makes it harder or impossible to craft invalid programs. When we're editing text files, a modern IDE will throw some red underlines under the text when we've written something that it knows won't compile, which is a massive step in the right direction. But contrast that with humble Scratch, which makes it structurally impossible to write an invalid program as you go (incomplete, yes, but an incomplete program is obvious because it will have unfilled slots). I wonder sometimes if tooling that treated the syntactic components of a language as things, not strings, would actually allow developers to move faster with some training.
OTOH, modern editing tools, such as "language servers", provide most of the advantages without the aforementioned issues.
Anyone who stays near to, or on, the bleeding edge of technology will know that no-code isn’t a real thing for them. Add some extra automation and boilerplate capabilities by all means, but software will always eat software.
"Code" isn't an end to itself. Many developers spend their hours, days and careers trying to think of the simplest, clearest way to specify solutions to the problems they work on. Code (and data) is the best general thing we've been able to come up with.
There can certainly be complexity arising from the code itself (more generally -- are you spending your time solving problems in the solution space or problem space?) but you need some way to deal with the complexity inherent to the problem. If there's a better way to do it than code, I'd be more than happy to jump on it.
There are some good no/low code systems -- like spread sheets and some of the forms systems -- where they've found a powerful, flexible, yet simple enough abstraction. But these tend to form silos, and you need a ready escape hatch where the complexity of the underly problem exceeds the capability of the system (which is very common for anything useful).
It's still programming, just a trying to be nice. Here and there it makes programming worse by e.g. not being very object oriented sometimes, but overall it always tries to make everything as high level as possible.
High level programming languages on top of low level ones have been a hit ever since. The day I can plug together APIs and basic user management will be great: Make default user UI with login, profile, picture, make a twitter-style feed where everyone can subscribe to others. This I imagine possible within a day.
Ideally you also wrap some APIs for me so I can e.g. take my existing twitter feed and do stuff with it. We are not too far from all that, but if you want to do one custom step you are back at jumping in to a lower level and need to build components yourself and it's just even more annoying :).
It also has a way better chance with narrow use cases and is very successful there: chat bot builders, configuration of headless CMS admin UIs, analytics tools, KNIME even try machine learning and it looks wonderful.
In the end, cost and effort is much higher, than as if it were implemented properly in code from the beginning. You write a lesson learned, discuss it with the team and management, get an agreement to do it right the next time.
Then, a week later, a new project starts, you want to do it in code, but get overridden because it's a perfect use case for this great low code or no code tool you are using.
Source: every integration / middleware / ESB developer in every enterprise company.
So the question is how much of that power can you push to those end users vs what needs to be held by "proper developers". I could see tools like advanced versions of co-pilot expanding the scope of what people can do to the point where only very high scale, very universal things are built by "proper developers".
There's a plug-in for blender called Armory which does this. It's only for game development, but I think something like that could really revolutionize software development. Let people drag and drop, and customize.
I'm probably bias though, as I do contract work that is 99% replacing low-code solutions with something proprietary. I think it works out pretty good though. They usually have some sort of system in place and "working." Makes my job a lot easier as you can see the "shape" of their intent.
There's always going to be one or two things that bother a PM to the point of switching to some proprietary solution ;)
> “As it stands now, there seems to be a tradeoff between ease-of-use and control, and until someone figures out how to remove that tradeoff, there will always be a need for engineers who can fully manipulate software to meet the full range of use cases businesses (and individuals) need.”
we're constantly making this type of tradeoff as developers. It's not just a decision we make at the beginning of a project where we look at the requirements and say hey no-code might be the way to go here.
have you written a function for a library to hide information / details of how something works? that's a tradeoff between ease and control for the client.
now expose that through a GUI with some params and now you have "no-code".
sometimes that's ok. it's nice to have options!
I've seen in my industry, we used to spend ages making the most ridiculously complicated front-ends for complex tasks. Now finally we're starting to accept that these orgs will have people who can smack out a bit of Python and suddenly we get to stop wasting our time and focus on supporting those who accept they have to code.
No code/low code will always remain toy and brittle outside of demo-esqe use-cases and those who are willing to open a file in notepad and tinker will retain a significant advantage over the rest.
No-code is a "solution" to illiteracy. It is (snarky example alert) like taking all the cells in all the Marvel comics, cutting them out singly and arranging them in order (punch, horror, fly) and saying "now you too can write a story"
Yeah kind of.
But what we need is not No-Code. what we need are two things - more people who learn to code, and companies that make their data and processes accessible to code.
But it's like trying to start a marketplace - you need to attract the buyers and the sellers at the same time
Execs seem to love them.
They never seem to go far.
I am not speculating on why they never make it. It's easy to see why execs love them.
Spreadsheet programs are arguably the closest we got up to now, and that was a long time ago.
At the same time, "traditional" software development isn't going anywhere soon. In the short to medium term it may even become more valuable and sought after because an increasing number of technically minded people will enter the market at this new level of abstraction and never learn traditional software development at all.
For "enterprise software", I imagine a future of domain experts training/instructing AI minions to do things like process sale orders and returns - like the office clerks of the past, but silicon clerks. And if that, why not consumer apps etc. too?
The next "everything is bloated electron apps" is "everything is bloated AI models" ?-)
1. Insufficient skill to make such automation work
2. A large enough number of people are capable of making this happen, and after that, everyone else('s career) dies.
I for one welcome our new overlords.
I feel low code tools can only really disrupt development once they solve the problem of requirements gathering from customers/ end users and also formally describe change management in low-code as well. As long as there is ambiguity in requirements - code or low code makes no difference.
Tools like github copilot gives us a glimpse of how will be the tool that will revolutionize tech dev on day in the future IMHO.
I wouldn't. Bring on the new Hypercard.
We just keep looking at this from a developer perspective, but from a business perspective it's there.
On a shorter term, the disruption they can provide is similar to the one involving cryptocurrencies and blockchain: a lot of hype, grift, and few real applications.
> You'll never find a programming language that frees you from the burden of clarifying your ideas. (https://xkcd.com/568/)
We've all been there, from time to time you have a database table or whatnot that "makes sense" (its columns closely match what users of the software expect to see), and you really just need to expose CRUD operations, add half a page worth of validation and action buttons and then the app is done. (CRUD = standard db ops; CREATE, SELECT (Read), UPDATE, DELETE).
Why is the 'low-code automatisation' of that part wavering in and out of popularity? low-code solutions _can_ capture away the right kind of complexity here, no? And it's been tried. In many forms. Many times.
In the 90s, 'database-oriented software development' was very popular. FoxPro, MS Access, xbase, that sort of thing. You got the CRUD stuff for free, and all you were really doing was designing forms to lay out the various DB columns and maybe adding special scripted actions to certain buttons. That was pretty much it, already quite low code and trying to, I dunno, turn those scripts into more lego-brick-style low-code solutions seems feasible at that point, too.
The development environment was all in on this. The basic interface was a form designer. Then you'd click on a button in the form and 'add an action listener'. The other main view is your columns and tables view where you can click on things to 'add change listeners'. You blessed some form view as the 'main view' which loaded on app start, and that's how you build an app.
But FoxPro, MSAccess, that sort of stuff mostly died out. The vast majority of software, both consumer and business oriented, is written in java, python, C#, javascript - those sorts of languages. General languages where database support isn't even baked in - you need to add a dependency no less.
The concept was then reinvented: Rails (Ruby-on-Rails) with the notion of 'skeleton' generation, which didn't just generate the barest of bones ("Here is the source file containing the entry point, here is a project definition and all you need to do is edit the names") - but did a lot more than that, giving you a basic but functionally styled web interface for CRUD ops. The development 'model' of rails is then to just add new features and endpoints, and perhaps even replace these CRUD pages one day, until you're happy with your app.
But rails is far less popular today than it used to be, and whilst various web frameworks still offer really easy ways to toss up CRUD operations, it seems to me like it's less of a key feature, and various frameworks that don't have it or whose CRUD support seems like an afterthought are still quite popular.
Direct rails clones in other languages, such as Grails (for java), have pretty much died out.
Why?
It's the fact that "the low code experiment has been tried a ton of times and it has failed every time" that teaches me that low-code is doomed to fail. Unfortunately, it doesn't explain _why_ it fails. Just that it is likely to.
The good part of the bet is that most potential disruptions end not happening... But the exactly same median consensus is also reached about the disruptions that do end happening...