Live data from Hacker News

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

stackoverflow.blog

81–90 of 208 posts

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

#81
post #67

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…

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

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

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

#82
Most comments here are in agreement that a ton of programming is doing complicated things, and the complicated part is not "which letters do I press on this keyboard to make code loop a few times". Hence, low-code tools don't solve the right complexity problem. So let's move beyond that.

We've all been there, from time to time you have a database table or whatnot that "makes sense" (its columns closely match what users of the software expect to see), and you really just need to expose CRUD operations, add half a page worth of validation and action buttons and then the app is done. (CRUD = standard db ops; CREATE, SELECT (Read), UPDATE, DELETE).

Why is the 'low-code automatisation' of that part wavering in and out of popularity? low-code solutions _can_ capture away the right kind of complexity here, no? And it's been tried. In many forms. Many times.

In the 90s, 'database-oriented software development' was very popular. FoxPro, MS Access, xbase, that sort of thing. You got the CRUD stuff for free, and all you were really doing was designing forms to lay out the various DB columns and maybe adding special scripted actions to certain buttons. That was pretty much it, already quite low code and trying to, I dunno, turn those scripts into more lego-brick-style low-code solutions seems feasible at that point, too.

The development environment was all in on this. The basic interface was a form designer. Then you'd click on a button in the form and 'add an action listener'. The other main view is your columns and tables view where you can click on things to 'add change listeners'. You blessed some form view as the 'main view' which loaded on app start, and that's how you build an app.

But FoxPro, MSAccess, that sort of stuff mostly died out. The vast majority of software, both consumer and business oriented, is written in java, python, C#, javascript - those sorts of languages. General languages where database support isn't even baked in - you need to add a dependency no less.

The concept was then reinvented: Rails (Ruby-on-Rails) with the notion of 'skeleton' generation, which didn't just generate the barest of bones ("Here is the source file containing the entry point, here is a project definition and all you need to do is edit the names") - but did a lot more than that, giving you a basic but functionally styled web interface for CRUD ops. The development 'model' of rails is then to just add new features and endpoints, and perhaps even replace these CRUD pages one day, until you're happy with your app.

But rails is far less popular today than it used to be, and whilst various web frameworks still offer really easy ways to toss up CRUD operations, it seems to me like it's less of a key feature, and various frameworks that don't have it or whose CRUD support seems like an afterthought are still quite popular.

Direct rails clones in other languages, such as Grails (for java), have pretty much died out.

Why?

It's the fact that "the low code experiment has been tried a ton of times and it has failed every time" that teaches me that low-code is doomed to fail. Unfortunately, it doesn't explain _why_ it fails. Just that it is likely to.

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

#83
This line stood out to me:

> “As it stands now, there seems to be a tradeoff between ease-of-use and control, and until someone figures out how to remove that tradeoff, there will always be a need for engineers who can fully manipulate software to meet the full range of use cases businesses (and individuals) need.”

we're constantly making this type of tradeoff as developers. It's not just a decision we make at the beginning of a project where we look at the requirements and say hey no-code might be the way to go here.

have you written a function for a library to hide information / details of how something works? that's a tradeoff between ease and control for the client.

now expose that through a GUI with some params and now you have "no-code".

sometimes that's ok. it's nice to have options!

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

#85
post #30

Earlier quoted context omitted.

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…

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.

IMO, Zapier is a little different because it's connecting disparate APIs.

Disclaimer: I work for Zapier.

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

#86

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

> this would have been impossible for a single person using traditional tools such as Java

I don't think so?

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

#87
To a degree... but the problem with a lot of "low/no-code" is the people using it, lol. I'm not a musician, so even with better/different tools, I can't compose a good song. Same goes for a lot of low-code solutions I've come across. The design/architecture causes a lot of problems. The big ones I've seen are ppl designing without thinking about side effects and responsibility of "modules."

I'm probably bias though, as I do contract work that is 99% replacing low-code solutions with something proprietary. I think it works out pretty good though. They usually have some sort of system in place and "working." Makes my job a lot easier as you can see the "shape" of their intent.

There's always going to be one or two things that bother a PM to the point of switching to some proprietary solution ;)

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

#88

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

Excel wizards who consider themselves non-programmers, end up with what I would consider programming skills.

And this is the rub with low/no-code solutions. To use them effectively, you have to have some programming skills already.

They are perfect for lazy programmers, but less so for "Citizen Developers". At least, I haven't come across any I was really impressed with as a "Citizen Developer" platform. I would happily take references to any I should check out that might succeed at enabling non-coders to build production solutions.

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

#89

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…

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

Post reply on HN