Live data from Hacker News

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

stackoverflow.blog

51–60 of 208 posts

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

#51

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

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.

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

#52
post #32

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…

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…

Great comment, fully agree.

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

#53

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…

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.

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

#54

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…

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.

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

#56

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…

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

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

#58
post #30

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…

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…

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.

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

#59
Well... for no/low code to take over everything, we'd need 10x the developers to create it all and then probably 20x the developers, in perpetuity, to handle the integrations.

"Code" isn't an end to itself. Many developers spend their hours, days and careers trying to think of the simplest, clearest way to specify solutions to the problems they work on. Code (and data) is the best general thing we've been able to come up with.

There can certainly be complexity arising from the code itself (more generally -- are you spending your time solving problems in the solution space or problem space?) but you need some way to deal with the complexity inherent to the problem. If there's a better way to do it than code, I'd be more than happy to jump on it.

There are some good no/low code systems -- like spread sheets and some of the forms systems -- where they've found a powerful, flexible, yet simple enough abstraction. But these tend to form silos, and you need a ready escape hatch where the complexity of the underly problem exceeds the capability of the system (which is very common for anything useful).

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

#60
post #46

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