8 ms·

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 com

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.

ren_engineer 4y ago
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.
failrate 4y ago
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.
- galangalalgol 4y ago
  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.
- danielvaughn 4y ago
  It's like a very fast car that's perfect for driving straight into a ditch.
- duped 4y ago
  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.
  - rzwitserloot 4y ago
    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!'
- habeyer 4y ago
  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.
deleted 4y ago
[deleted]
snarf21 4y ago
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.
88913527 4y ago
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.
- burlesona 4y ago
  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.
  - pessimizer 4y ago
    That's an interesting perspective. No-code tools to enable businesspeople to write good specs.
    - soco 4y ago
      That's just the start. Soon the business people will become overwhelmed and pass ALSO this task to the developers.
  - ianmcgowan 4y ago
    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.
metadaemon 4y ago
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.
- danielvaughn 4y ago
  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 https://matry.design/demo
- pessimizer 4y ago
  > 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.
  - metadaemon 4y ago
    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.
q-big 4y ago
> 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.
- stirfish 4y ago
  Can you help me be smarter?
  - q-big 4y ago
    > Can you help me be smarter? 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 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.
- danielvaughn 4y ago
  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.
  - q-big 4y ago
aeruder 4y ago
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. [1] https://i.imgur.com/KsVliNE.png https://i.imgur.com/KsVliNE.png
- actionfromafar 4y ago
  The graph makes for a good laugh. 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.
  - galdosdi 4y ago
    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.
- danielvaughn 4y ago
  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.
treis 4y ago
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.
jerf 4y ago
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.
graypegg 4y ago
Exactly. It’s procedural writing at the end of the day: designed by humans, for humans to write.
ehnto 4y ago
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.
- danielvaughn 4y ago
  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.
  - basch 4y ago
    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.
    - fendy3002 4y ago
      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.
    - 4y ago
rvense 4y ago
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.
bartread 4y ago
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.
pxue 4y ago
Low code allows "less" sunken cost when the inevitable misalignment of requirements happen. 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.
- ElectricalUnion 4y ago
  > In software we dive into code way to eagerly and way too early in the product process. 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.
sbf501 4y ago
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).
- hkleppe 4y ago
  I see it differently. 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 :)
  - ehnto 4y ago
    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.
- drewcoo 4y ago
  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.
hkleppe 4y ago
> 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
- chasd00 4y ago
  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.
  - danielvaughn 4y ago
    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?”
  - to11mtm 4y ago
    > 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.
catwind7 4y ago
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
civilized 4y ago
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.
bloqs 4y ago
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
andsoitis 4y ago
I don't disagree. 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.
gautamdivgi 4y ago
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”.
deleted 4y ago
[deleted]
cmiller1 4y ago
I always have the same response to discussion of low/no-code and graphical programming environments: 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"
Footkerchief 4y ago
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.
analog31 4y ago
A contributing factor is the belief that "everything graphical is easier."
habeyer 4y ago
Agreed 100%. You CANNOT solve complexity by just making things "visual". Biggest low/no-code mistake.

ren_engineer 4y ago

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.

failrate 4y ago

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.

galangalalgol 4y ago
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.
danielvaughn 4y ago
It's like a very fast car that's perfect for driving straight into a ditch.
duped 4y ago
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.
- rzwitserloot 4y ago
  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!'
habeyer 4y ago
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.

deleted 4y ago

[deleted]

snarf21 4y ago

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.

88913527 4y ago

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.

burlesona 4y ago
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.
- pessimizer 4y ago
  That's an interesting perspective. No-code tools to enable businesspeople to write good specs.
  - soco 4y ago
    That's just the start. Soon the business people will become overwhelmed and pass ALSO this task to the developers.
- ianmcgowan 4y ago
  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.

metadaemon 4y ago

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.

danielvaughn 4y ago
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 https://matry.design/demo
pessimizer 4y ago
> 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.
- metadaemon 4y ago
  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.

q-big 4y ago

> 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.

stirfish 4y ago
Can you help me be smarter?
- q-big 4y ago
  > Can you help me be smarter? 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 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.
danielvaughn 4y ago
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.
- q-big 4y ago

aeruder 4y ago

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. [1] https://i.imgur.com/KsVliNE.png https://i.imgur.com/KsVliNE.png

actionfromafar 4y ago
The graph makes for a good laugh. 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.
- galdosdi 4y ago
  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.
danielvaughn 4y ago
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.

treis 4y ago

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.

jerf 4y ago

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.

graypegg 4y ago

Exactly. It’s procedural writing at the end of the day: designed by humans, for humans to write.

ehnto 4y ago

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.

danielvaughn 4y ago
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.
- basch 4y ago
  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.
  - fendy3002 4y ago
    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.
  - 4y ago

rvense 4y ago

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.

bartread 4y ago

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.

pxue 4y ago

Low code allows "less" sunken cost when the inevitable misalignment of requirements happen. 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.

ElectricalUnion 4y ago
> In software we dive into code way to eagerly and way too early in the product process. 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.

sbf501 4y ago

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).

hkleppe 4y ago
I see it differently. 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 :)
- ehnto 4y ago
  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.
drewcoo 4y ago
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.

hkleppe 4y ago

> 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

chasd00 4y ago
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.
- danielvaughn 4y ago
  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?”
- to11mtm 4y ago
  > 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.

catwind7 4y ago

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

civilized 4y ago

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.

bloqs 4y ago

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

andsoitis 4y ago

I don't disagree. 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.

gautamdivgi 4y ago

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”.

deleted 4y ago

[deleted]

cmiller1 4y ago

I always have the same response to discussion of low/no-code and graphical programming environments: 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"

Footkerchief 4y ago

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.

analog31 4y ago

A contributing factor is the belief that "everything graphical is easier."

habeyer 4y ago

Agreed 100%. You CANNOT solve complexity by just making things "visual". Biggest low/no-code mistake.