I've seen a lot more interest for this kind of tool in enterprise environments recently. Never seen this kind of interest before. I'm curious on how this is going to pan out.
It has been a perennial dream for six decades. The creators of Cobol and Fortran thought that was what they were producing! (Not literally no-code, but the notion that computing by non-specialists would result from putting assembler and other hardware-oriented knowledge under the covers.) After that, there were several waves of hype and disillusionment, though that seems to have dampened down in the 21st century.
Spreadsheet programs are arguably the closest we got up to now, and that was a long time ago.
I was involved with a project to bring these low-code / no-code tools into a financial company. I think its almost all driven out of the idea that software developers are expensive and development takes a long time. The "Dream" is that the business analyst or financial analyst or whomever automates their own job away, or that they write the business process (While being paid half as much!). Of course the issue is that they can't easily do this while they are also doing their own job, mistakes are made and they need "real" software developers to come in, it takes just as long or longer, etc.
I think the potential value for niche line of business apps. The kinds of things that used to be drive by a spreadsheet can now be driven by a spreadsheet-driven mobile app with better defined workflow. I think this won't really displace much, if any, real development work. It will open up a lot of smaller tasks to automation. The kind of things that weren't valuable enough to warrant an expensive development project.
My main issue with low-code/no-code is that it attempts to solve the complexity problem, without understanding what "complexity" is. Code is perceived to be complex, but when you look deeply into what people mean when they say that, it's almost entirely a social perception. They see these weird characters and it looks like gibberish and they assume that the people who understand this gibberish are somehow on another level of intelligence.
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.
Yes, and I have never struggled to execute something complex as I have with no-code tools.
Nocode usually makes the HelloWorld trivial and anything meaningful more challenging than it would be to do in a general purpose language.
This has been my universal experience with graphical code generation. Simple tasks are super simple, and easy to change, all good there, but the second you try to take that and grow it to do something you actually care about, it actually increases the complexity, as well as lengthening your development loop.
This isn't just true of NoCode, it's endemic to young tools. These products are over-optimized toward low friction on-ramps because the only thing that matters is growth in DAUs.
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.
Java is somewhat legendary for being rather overly wordy. But, if a new language starts off its list of 'why should you use this' with comparing how to write to the console (java: `System.out.println`, other languages: a simple `puts` or `printf`) always strikes me as silly and turns me off of the language.
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!'
If I made a tool that was good for large codebases, I'd demo it by making a video ostensibly demonstrating someone unfamiliar with a large codebase reading a simple JIRA ticket for the first time and then using the IDE/language/toolset to explore the codebase and figure out what actually needs to be done, the whole time narrating and pointing out each feature of the language, tool, IDE, etc that makes this experience quicker, easier, better.
It could even be a relatively fake example and I think it would still land if your audience has had experience exploring large codebases
> 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 low-code as a "generalized" solution will ever gain traction with developers, but has a future as small, focused tools to solve specific dev problems.
Complexity is definitely the problem. I think the main problem with most LC/NC solutions is that they offer TOO MUCH customizability. I think there will be more in roads when it becomes a little more opinionated. People always think they want all these features and weird use cases but they forget about any kind of 80/20 or 90/10 rules.
The problem is difficulty in developing the business requirement. I have to plead with Product owners to give me more than a few sentences about what it is they want to built. It makes no difference what the tool we use to express requirements is if we cannot have a firm grasp of the requirements themself.
This is actually the strongest case in favor of "no code" tools IMO. Get the PM to spend time actually modeling what they want, as close as they can get, in no-code tools. They get to bash their head against the wall for a while until they give up and bring in engineering. But now (a) the PM actually has some intuition around how complex things are, and (b) their no-code solution is probably a better approximation of a spec than they would have written.
Much the same experience using Excel - people describe a problem in English with a lot of glossing over of details, but asking them to mock something up in a spreadsheet brings home some of the complexities.
To expand on this, you will have to house the complexity somewhere. For low/no code tools, it's swept under the rug, or rather, under layers of abstraction.
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.
Totally agree. I've been working on a programming language for UI designers, but it's been years and I doubt I'll ever release it at this point. The idea was to offer a syntax that conforms to their vocabulary and mental models. So if you were designing a button:
elements
shape Wrapper
text Label
style Wrapper
fill: blue
style Label
content: Click Me
fill: white
edit: no harm in sharing the demo page that I never released. Warning - it's very broken. But it kinda works: https://matry.design/demo
> I'm sure that the futuristic lay-person will have a better basal understanding of technology and how it's made.
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.
I say it like I'm sure, but honestly I worry about this. It's possible we achieved such a technological peak that future generations won't be able to understand the basics; only the simplifications, leading to the premise of Idiocracy.
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.
> It's possible we achieved such a technological peak that future generations won't be able to understand the basics
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.
University professors in recent years have been finding themselves shocked that students don't understand how file systems work[1]. Additionally I recall hearing a teacher say that they were trying to teach something in a computer lab, and none of the students knew how to work a windowing system or multitask, and they only operated by having every program maximized and using one at a time, likely because it's the computing paradigm they grew up on, using smartphones and tablets.
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.
Exactly! I was going to comment on the same phenomena.
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.
You saw the same with cars. Back in say 1950, most car owners would know how to do basic maintenance and repairs, both because the cars was mechanically simpler, but also less reliable. With higher reliability and more complex cars, that is no longer the case. Now the same thing is happening with computers.
> They see these weird characters and it looks like gibberish and they assume that the people who understand this gibberish are somehow on another level of intelligence.
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.
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.
I myself had that perception before I learned how to code. I even still have that perception when it comes to math. Every single time I hear mathematicians talk on HN I feel like I hear a whole new set of words I've never heard before, and looking at math diagrams makes my brain hurt. It makes you feel stupid, but it's just an illusion.
100%. I worked at a company that really went in hard on Agilent Vee for hardware testing in the early 2000's. Absolutely a thing where a manager saw a "Hello World"-like demo and was so impressed that they went 100% full buy in.
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.
I think this is very right. We have only scratched the surface in terms of creatively experimenting with the IDE UI to give the developer more ways to quickly explore and refactor code. Text in/text out is a serious loss in fidelity from the overall input/output capabilities of a computer.
I work out of a co-working space. A few months ago I walked past some people fidgeting with Zapier. Some (former) employee had built this crazy complex system of integrations, with connections going back and forth everywhere. It looked very much like this diagram, and I couldn't help but laugh, because it's the same kind of problem that coders face on a daily basis.
Yeah, I think Zapier is one of if not the only example I've come across in my software dev career of a low-code-type tool that devs will reach for before doing stuff by hand.
Great example of where low-code is a better alternative for a very narrow use case of development.
- 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.
In automotive, development of control algorithms for the engine is entirely “visual”, through simulink/matlab. You design the model on simulink, then it generates the C code. I don’t have direct experience outside the automotive sector, but I believe that this approach is used in other sectors like aerospace. Maybe designing models is better than writing low level code for control algorithms?
I don't have any experience in the automotive sector. But when you say that the development of control algorithms for the engine are visual, I immediately thought finite state machine. My question: Are they finite state machines or is there more to it than that?
Depending on how complex, it would be a hybrid system. You have finite discrete states, but also continuous dynamics that need to be controlled (like a PID)
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
In power generation control when electrical engineers are discussing or analyzing the behavior of a governor or exciter block diagrams representing transfer functions are used. I would program turbine controls primarily in function block diagrams since it a great visual representation of the algorithms that makes
It easy for some one to understand and observe how it works. I started with computer programming and it was quite an adjustment in my way of thinking to implement algorithms this way but no question it is the right tool for the job in controls.
Yes, IIRC some aerospace companies also use simulink. It's popular with safety critical stuff.
> 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".
The single most important point that is keeping visual programming from ever being taken seriously in corporate settings is the fact that there are currently no version control compatible with it (for good reason). You can't collaborate without version control.
IMHO there's no such thing as "no code" or "low code". It's "bad code". Or less catchy programming languages that usually lack the tools and features that widely used programming languages do.
The classic Mythical Man Month makes a crucial distinction between "accidental" and "essential" complexity. Accidental complexity is stuff that it is in your solution, but is not necessary. For example, you added a layer of abstraction that ultimately isn't necessary and doesn't have benefits outweighing the costs. Essential complexity is intrinsic to the problem itself. For example, if you write software to help you file your taxes, you have a certain fundamental amount of complexity that no amount of clever code can get you around, because the problem itself is complicated.
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.
Perfect way to say it, yes. It's a mirage in the desert that we'll be chasing forever, because to the business stakeholder's eyes, the water is just right there over that hill.
I venture the opinion that the overwhelming majority of the complexity on most current software is accidental. It's the kind of share that you measure in 9s, not on raw percentage.
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.
Everything you said would happen, I saw happpen. I literally witnessed this.
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!
I think any discussion about no-code/low-code and if it's effective has to take into account Unreal Blueprints. Game development is full of inherently complex problems, but some people are able to pull it off with Blueprints. What's important about that though, is that Blueprints live inside a complex codebase focused on game development, so the graphical/node based toolbox you have is extremely powerful because developers have coded those blocks and tools for you. The majority of the engine is abstracted away.
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.
I almost put in my original comment that no-code/low-code becomes more useful as it gets more specific to a domain. Game dev is a perfect example - building complex shaders becomes much easier with a visual editing tool. I think of Google Sheets as a highly useful tool in this space. Same for Google Data Studio.
Isn't the domain of most no-code/low-code "business process"? It's some glue between systems to collect or input data. It allows the expert on the business process to directly translate the manual process without others.
I think no, since usually the condition for each Business process state is usually complex, which no code / low code won't help much and is usually worse on performance compared to native implementation.
Low-/no-code environments are really great for exposing domain-specific landscapes to non-coders, but that significantly reduces the hype value of the lingo, which aims to convince buyers that they can replace those pesky non-specific domain problem spaces and coders with capex and a smidge of opex. The value proposition of these products is the same as before because this is a repackaging of fourth-generation languages, and the economics have not changed.
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.
Yeah, this is the reality. I'm not going to name the tool but I went to a training session for one of these things recently and it pretty quickly devolved into programming: looping, branching, conditionals, etc. Except rather than raw text this was rendered as (basically) a set of bubbles containing icons and text, and with arrows between them. It was even vertically oriented the way code is.
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.
The hard part of my job is rarely the programming itself. The hardest part is figuring out what to build, in enough detail for the blinking computer to understand it.
Automobile engines are also very complex, but no one talks about no-mechanic cars. In highschool where I grew up, the bottom academic 50% of boys ended up being mechanics of one type or another. At one point in time, being an auto mechanic was an elite, rare profession, and that complexity was encapsulated as something that low-performing academic students could bank on for a career.
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 :)
I can imagine a few instances where giving a node-editor to business would have been a way better solution than having us re-implement it in code continuously. That said, that was always in the context of a larger, domain specific piece of software. Where I think low-code falls flat is trying to be a general purpose programming tool, which means for someone to do their domain specific tasks, learning how to make a general purpose program from scratch is a big ask. I think low-code editors should focus on this portion of the user's journey. Getting data in, data storage, manipulation, image processing, reaching out to APIs, all that stuff needs to be as easy as possible.
Low code isn't about tinkering under the hood. It's about going places.
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.
Yes, I agree. I thought that was obvious in my response. Modern cars are "low code", so mechanics don't need advanced degrees to fix them. Also: "the complexity is eventually abstracted away", which is exactly what you are saying.
> My main issue with low-code/no-code is that it attempts to solve the complexity problem, without understanding what "complexity" is.
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
The magic will always be in deciding where to stop using low/no-code and start using actual code. domain specific and opinionated low/no-code tools with clear boundaries on what the tool can and can't do would be a good thing but the markets would be small and that's a bad thing.
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.
> 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.
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.
Agreed. The cynic in me hears business execs saying “we want non-programmers to be as effective as programmers”, and what I really hear is “we don’t pay these people nearly as much, can we get them to do it instead?”
formalized expression is detail and while that detail may not be complex for a programmer it can be completely meaningless to a user. I agree with you in part but i think worth recognizing that if we all had this attitude then we wouldn't be building business applications / consumer apps for non-developers
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
Reminds me (once again) of the famous Salesforce marketing campaign, "The End of Software".
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.
This is the issue. I've worked a lot with low and no code tools, and what happens is the complexity becomes absolutely ridiculous to do very simple operations.
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.
If you work for a company where software is not a core function the explanation you posted will sound like an alarming number of dollars to your executives.
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”.
it just comes down to abstraction and associated tradeoffs. Low-code/no-code fundamentally isn't all that different from the difference between using Python vs a lower level language.
I basically agree that most complexity lies in correctly formulating ideas -- though depending on language, there is a great deal of time and effort wasted on the overhead of expressing those ideas.
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.
Asp.net Forms and WinForms are much much much better rapid development tools than the kinds of bubble/retool etc. The issue is that lots of very young people have very limited set knowledge about the choices available to them.
I do a fair amount of pre-seed and angel investing and I've seen a _massive_ increase in the number of very early businesses that have a "product" that they've been able to build with no/low code tools. It gives non-tech founders a set of options they've never had before, in my experience.
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.
I'm currently contracting for a client that uses a no-code tool to build their product, and this is exactly my opinion. If you're building a software startup, the only scenario where it makes sense to use a no-code tool (e.g., Bubble), is if you don't know to code. And even then, you will need to replace everything with proper code once you start growing.
Of course, this is a bit different for low-code tools that are used internally etc.
Basically this space is deliver multiples on what engineer team would bring at multiple discounts. It's not really a sustainable model because they are constantly viewing it as a cost center even with the productivity no-code tools. So the moment some open source version is released or they see a cheaper solution they will flock to it especially if you allow easy migration. I've had requests from companies who were doing well with the no-code SaaS but felt they were being held hostage/realize they want an internal tool they own because their requireents always devolves past what no-code tool can do.
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 a non-tech founder building a app on building, basically very CRM/Data centric for a specific industry vertical I work in professionally.
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!)
> 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.
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.
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.
Unreal Blueprints isn't low code, it's just code, and it doesn't need to replace "real" coding because it is real coding.
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.
My hope is that no code / low code disrupts the waiting for developers to have time to do stupid tedious stuff that changes randomly. My perception is the tech industry recruits a ton of people into it that aren’t particularly interested or suited to try to triage the amount of simplistic logical manipulation of data and processes that doesn’t require going through a full development cycle. By offloading some portion of that back to end users you can give them an inflection point to work without danger while keeping engineers focused on the complex parts of the system - and hopefully hire less people into tech teams who aren’t engineers.
As someone who got their start in tech with a low-code environment (ServiceNow reporting) I have found the true value of low code is the ability for business/ops teams to create tools that serve their needs without waiting on a team of "real" developers to make time for them.
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.
I 100% agree on the savings of real developer time when end users can self service.
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.
> 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?".
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?
> 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.
> As someone who got their start in tech with a low-code environment (ServiceNow reporting) I have found the true value of low code is the ability for business/ops teams to create tools that serve their needs without waiting on a team of "real" developers to make time for them.
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.
> the true value of low code is the ability for business/ ops teams to
create tools that serve their needs without waiting on a team of
"real" developers to make time for them.
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.
They already have, in many ways. Look at the "modern data stack" -- the idea that you can replace a ton of bespoke ETL platform and implementation with managed, low-code tools. It's been really successful.
But this and other examples don't feel like disruption though because there's still an ever expanding universe of work that requires code.
No. Not general purpose application development. Not ever.
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.
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.
Thank you for expressing exactly what I’ve felt. In my experience something like Retool lets you spin up an incredible amount of functionality very quickly, and it also does a great job of helping you find the boundary where you should do something elsewhere.
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.
I've used Retool as UI and Airtable as DB for so many tiny custom apps, it's great. Retool ends up being used to create "constraints" on top of Airtable in a way that enforces how people add / view records.
I disagree with this opinion
"Anyone marketing a low or no code tool to developers is targeting the wrong audience"
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.
What happens to the software built with these tools when the no-code tooling company goes under? Do you have 30 days to port everything you did to something else before they turn it all off?
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.
They are already. I consult for a lot of hyper-early-stage YC startups as they formulate their plans and I've had two separate clients in the past 6 months go the no-code route to build their MVP. At first I was against it, but having seen these clients go through it I would say it is much cheaper and less risky and gives developers an extremely good blueprint for when the founders inevitably decide to go beyond the MVP stage and build their own codebase. No-code platforms are a great way for non-technical (and even technical!) founders to do that hard product work of figuring out what they actually want their app to do and how each screen should work. Things like figma let you do this too, but I find founders will often make something in figma with logic holes or missing flows if they aren't thinking like an engineer. The no-code platforms force you to make these decisions because you'll notice the holes the moment you go to use the app instead of noticing them when your developers go to implement something that doesn't make sense. Much cheaper way to do early iteration.
It depends on the application. In this case both clients were using a no-code system used by big fintech players like Goldman Sachs that costs $150k for a one year license.
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.
Having used low-code tools successfully to build ERP systems for the past few years.
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.
One thing I’ve found is that if you put something together in thirty minutes you’ll get much more detailed requirements because end users now have a tangible thing to organize their thoughts around.
I've recently been building a business directory using Bubble.io.
It took me about half a day to do tutorials and another half day playing around just to learn the platform.
After that, I was able to build this business directory, including Stripe payment integration, some reasonably advanced Google Maps and search / categorisation functionality.
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.
For everyone saying no, this is exactly what Shopify, and arguably Wordpress are. These things have already disrupted tech development. I think the real question is how much complexity can they take on, and I think they’re largely near the end of that curve.
Good point. Not too different to the application surface of AI where nocode is similiar to general AI but instead of aiming for that we're now learning to scope down to expert systems to see real gains.
I think Wordpress is a great example. I recently tried making a simple website using Wordpress's visual layout editor, and it was absolute hell. The process consists of fighting with unlabeled icons, convoluted UI state that is controlled by mouse movements apparently, shit jumping around all over the place when you add/remove stuff, and a ton of other terrible UX decisions. It felt like I was trying to perform a satanic ritual with my mouse.
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 difference is that Shopify and Wordpress are for well-defined solutions (shopping, blogs, landing pages), but are NOT viable for custom software applications.
Eventually, yes. But we will be approaching AGIs at that point.
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.
Unreal Engine Blueprints have been a game-changer for me personally, no pun intended. The rapid prototyping, API discoverability, and total immunity to 99% of dumb syntax errors which drag-and-drop visual programming provides has been a great help to learning Unreal. At the end of the day my ambitions are bigger than what I can efficiently build with Blueprints, but they're a great starting point for demos and small one-off applications.
207 comments
[ 2.9 ms ] story [ 236 ms ] threadSpreadsheet programs are arguably the closest we got up to now, and that was a long time ago.
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.
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.
[1] https://i.imgur.com/KsVliNE.png
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.
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.
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
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.
But this and other examples don't feel like disruption though because there's still an ever expanding universe of work that requires code.
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.
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.
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?
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.
Back-end feels really risky to me, because visual logic builders are just so limiting compared to code.
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.
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.
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)
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.