Live data from Hacker News

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

stackoverflow.blog

71–80 of 208 posts

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

#71
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…

Getting flashbacks to programming ABB ACS800 motor controllers with some hideous block diagram based thing many years ago. Oh god.

We also had a ton of horrendous LabView spaghetti which was even worse.

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

#72
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…

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.

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

#73

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…

> 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

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

#74

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…

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

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

#75
Well, no code and low code solutions are in practice more code. You use a tool, that is supposed to solve a trivial or a simple problem, and it works great until the first change requests come. With the second or third change request, the complexity is already so big, that no code is not a solution any more. But then, you have sunken costs, and no approval to rewrite. So, you keep adding a workaround around a workaround and another layer of patching or complexity, until a few years later you finally get an approval to ditch the no-code tool and rewrite using an actual code.

In the end, cost and effort is much higher, than as if it were implemented properly in code from the beginning. You write a lesson learned, discuss it with the team and management, get an agreement to do it right the next time.

Then, a week later, a new project starts, you want to do it in code, but get overridden because it's a perfect use case for this great low code or no code tool you are using.

Source: every integration / middleware / ESB developer in every enterprise company.

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

#76

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…

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

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

#77
post #28

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…

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

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.

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

#78
Disrupt, yes. Replace, no. Programming is moving to ever higher levels of abstraction. It's just a continuation of the trend. You'll still have the lower levels when you need them. It reminds me of WordPress. It will get the job done for most people but at the end of the day it's a piece of crap.

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

#79

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

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

#80
I think no code/low code solutions certainly have a place, but the way they're currently designed is not necessarily helpful (I've worked on replacing integromat and automate.io solutions in the past). Those solutions are fine, for the most part, but they're main flaw is that in order to get anything done you have to integrate them with other tools/software, which means that you're limited by what parts of the api the developers exposed to the no-code. That and the abstractions they produce on the UI end can be confusing and difficult to navigate. That's less their fault and more of an outcome from being a shiny new tool trying to do everything, but it results in a solution that doesn't really work for the people who would go for a low-code solution in the first place.

A good model in my mind is Excel. The amazing part of Excel is that it can be used as a no-code tool, a low code tool, and extended with code macros. Even self-described non-coders who would otherwise be intimidated often use to extreme productivity. It's extremely visual, straightforward, and self-contained for the most part. The fact that it's so well documented as well is also hugely important. The no code solutions I've seen and worked with usually are fairly lacking in this regard, but excel has fairly clear documentation, the famous f1 key, and a support line[^1] which makes it a more default choice. The only problem is that integrating it with your other tools relies on either 3rd party plugins, a coder, or integrating specifically w/ other ms software.

[^1]: I had a professor state in a comparison between MATLAB and Python that the reason to choose MATLAB was that they had a customer support line. This wasn't a CS professor, so you shouldn't underestimate how much value is placed on talking to a human rather than RTFM by non-coders.

Post reply on HN