But this and other examples don't feel like disruption though because there's still an ever expanding universe of work that requires code.
Will low and no code tools ever truly disrupt tech development?
21–30 of 208 posts
Re: Will low and no code tools ever truly disrupt tech development?
#22My 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 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.
Re: Will low and no code tools ever truly disrupt tech development?
#23My 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.
Re: Will low and no code tools ever truly disrupt tech development?
#24But niche applications or parts of applications might be. We see lots of “apps” that are spreadsheets or old access databases. In games/vfx and sound you see “shader graphs” and “audio pipelines” take over the job of code for parts of a codebase.
Learning tools with puzzle pieces for code statements aren’t “low code” they are just an accessible way of writing regular code. The amount of code created is typically much larger and the complexity higher than with a regular language.
Regular program code is the low complexity answer to general purpose software development.
Re: Will low and no code tools ever truly disrupt tech development?
#25Instead of hiring developers to do a 2-month project to build us a suite of admin tools, I built them myself in Retool over the course of a couple of days.
For a non-developer, maybe we're still far away from disruption. Excel seems to be the programming platform of choice for most people anyway.
But for developers, these things turn you into RoboCop. It's amazing how much I can get done now that I don't have to worry about UI, build pipelines, etc.
Re: Will low and no code tools ever truly disrupt tech development?
#26Re: Will low and no code tools ever truly disrupt tech development?
#27My 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.
Re: Will low and no code tools ever truly disrupt tech development?
#28My 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…
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.
Re: Will low and no code tools ever truly disrupt tech development?
#29I do a fair amount of pre-seed and angel investing and I've seen a _massive_ increase in the number of very early businesses that have a "product" that they've been able to build with no/low code tools. It gives non-tech founders a set of options they've never had before, in my experience. That obviously isn't viable for all early businesses and even the ones it is viable for eventually need to hire engineering teams…
Of course, this is a bit different for low-code tools that are used internally etc.
Re: Will low and no code tools ever truly disrupt tech development?
#30My 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…
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.