Live data from Hacker News

Will low and no code tools ever truly disrupt tech development?

stackoverflow.blog

111–120 of 208 posts

Re: Will low and no code tools ever truly disrupt tech development?

#111
Essentually asking "can newer tech become easier to use and more accessible". The answer is yes. Ive seen juniors struggle with django but make quick progress with hasura. I know plenty of developers who still dont use snippets. As far as im concerned to say that low code or no code couldnt disrupt tech is to say that software can't become easier to make or more accessible to people out of collage which i dont believe. Big problem these days is that tech has become more complex because we make it more complex. It doesnt always have to be that way. Enforcing good taste will be an interesting challange but just like easy to use guns made archery redudant for war, easy to use low code/no code tools will help take care of the urgent issues that arent important. That'll free up dev time for other things.

Re: Will low and no code tools ever truly disrupt tech development?

#113
post #46

Earlier quoted context omitted.

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 deve…

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.

Re: Will low and no code tools ever truly disrupt tech development?

#114

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…

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.

Re: Will low and no code tools ever truly disrupt tech development?

#115
post #70

Earlier quoted context omitted.

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 futuristi…

Anecdotally, most kids I know only interact with devices that feature strong guard rails like phones and tablets. Those kids are generally more ignorant of how software systems work than someone who grew in the 2000s.

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.

Kind of a sad paradox.

Re: Will low and no code tools ever truly disrupt tech development?

#116
I think it's useful to flip the script a bit and ask this question: why are software developers so often stuck writing software with their only abstraction available being text? Isn't that working with one hand tied behind their back?

I do a lot of work in geometric tools, and the fact that the best thing that we have for unit tests is to painstakingly construct objects by specifying their coordinate space hurts. Our team gained a lot of velocity on building and maintaining unit tests by simply writing a tiny graphical tool to convert back and forth between a text representation of a coordinate space and a visual representation, because visual presentation is far better for the average human than a text description for a bunch of circles and rectangles. The signal gets lost in the noise.

I also still think there's meat on the bones of tooling that makes it harder or impossible to craft invalid programs. When we're editing text files, a modern IDE will throw some red underlines under the text when we've written something that it knows won't compile, which is a massive step in the right direction. But contrast that with humble Scratch, which makes it structurally impossible to write an invalid program as you go (incomplete, yes, but an incomplete program is obvious because it will have unfilled slots). I wonder sometimes if tooling that treated the syntactic components of a language as things, not strings, would actually allow developers to move faster with some training.

Re: Will low and no code tools ever truly disrupt tech development?

#117
I'm not worried, if anything I can see the latest crop of tools creating additional opportunities for traditional developers. I know of freelancers who get a lot of work lifting and shifting previously successful lc/nc solutions developed in Excel or Access.

Re: Will low and no code tools ever truly disrupt tech development?

#118

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…

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

Re: Will low and no code tools ever truly disrupt tech development?

#119
post #113

Earlier quoted context omitted.

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.
Post reply on HN