I find it interesting that coders seemingly are fascinated by no-code tools. I mean these things have been around forever, iterating in development.
I've recently had the idea that the real problem isn't ease of use and effectivity of these tools, but rather that people who don't code just aren't too interested in developing things. After all, if they were, they'd probably also be interested in learning to code. So I'm not too sold on the idea that these kind of tools will one day make developers go out of business.
My take on it is that no-code misunderstands the problem it’s trying to solve. The root assumption of any tool of this kind is that code is complex. Code isn’t complex, it’s simple. Because it’s simple, it’s flexible, and because it’s flexible, it’s often used to solve complex problems.
Business people see these complex problems being solved by code and think that the code is what is complex. They don’t understand that the business logic at the heart of the product is what creates the complexity, and that this complexity is still going to be there even if they use a drag-and-drop interface.
I dont think it's quite so simple. Maybe 70% of business problems fall into a camp that no code tools can deal with and a long tail of 30% that do not.
The problem is that:
A) No code tools rarely provide good guidance as to where that 70/30 split lies.
B) It often takes a good coder to figure out when you've run into this square peg round hole problem and if you use a NCT you probably dont have one to hand and non technical users are SO bad at this (they will often think that they are the problem).
C) No code tools often end up reinventing programming languages really badly to bridge that gap instead of bridging like they should in an effort to keep users on their platform and because designing programming languages badly is fun!
D) As a result, most people not only misrecognize that 30% long tail and misapply the solution.
As a result no code tools have a perpetual allure until they get used on slightly too complex a problem at which point they become uber brittle and everybody starts tearing their hair out.
Sometimes the rigidity of the no code tool is baked in, which is even worse (e.g. like this one's bad mobile UX).
This is a great response, I agree. One thing I'll add onto point A is that I think it's sometimes impossible to know which side of the 70/30 you're on until the rubber has hit the road and you're deep into implementation. Which of course, complicates the whole thing even further.
Take this recent experience of mine - I'm helping someone build a teletech system with Twilio. Nothing too crazy, just connecting customers to a service provider. Seems like the perfect candidate for NCT - heck, even Twilio offers their own in-house NCT (Twilio Studio).
I just started building it yesterday and a literal avalanche of questions hit me. What if the call drops? What if the customer isn't happy with the service and wants to speak to someone else? What about (x/y/z) concerns?
Before beginning I would have put this project square in the 70%, but now I'm convinced we're in the 30%.
That's only half the story. Bigger hurdles are the framework fatigue and the constant of having to keep things up to date even after you've got a "complete" product. This is why you see shadow IT in the form of MS Access DBs and spreadsheets that (no matter how terribly implemented) won't die.
With no-code, those at least go away.
You're no longer having to deal with unnecessary complications of having to learn or deal with WebPack, etc, and you're no longer needing to stay in an endless cycle of dependency hell updates.
I've experienced this too, and it's a reason I'm building a reactive programming language. One way to think about it is a headless spreadsheet. https://www.adama-platform.com/
I think this is there the real solution lies to this problem. We don't need another drag-and-drop, we need to change how we think about code. I'm building a "programming" language specifically for UI designers. I think high level DSLs are the future.
I wasn't clear... I meant the hurdles go away. Spreadsheets from 90s versions of office still work just fine, whereas my nodejs app from last year is another story
>>> I find it interesting that coders seemingly are fascinated by no-code tools.
I think it would be mostly management who would be interested in no code tools. I understand, the allure of not needing a coder, anyone can create an application etc.
In my experience it is not really management but more various stakeholders and product developers who just want to implement ideas without having to ask for dev time and then wait for the project to be prioritized and hopefully eventually implemented. They do not like the dev team as bottle neck and gatekeeper.
But what that basically means that everyone becomes a developer which often ends up in s huge mess. Using no code tools is not much different from writing code. And letting a bunch of unskilled devs loose on your code base is generally stupid.
I'm management and the primary developer. (We've got a super small tech team.) I look forward to no-code tools so I can get designers and others tackling less complex problems/projects that would otherwise take up my development time. The hope is that I'd be able to focus on more challenging things, much like how open source relieves developers from building yet another [insert here].
I’ve seen plenty of unmaintainable solutions written using Excel and VBA, FoxPro, Access etc.
In my recent experience, the only “low code” solution that may be feasible to non developers will be something like ChatGPT.
I am working on a project now and it does as well as junior developers writing well written, commented logical Python code when you give it your “business requirements” in plain English.
While I wasn’t too surprised that it knew about standard Python libraries that work with xml, Yaml, json, etc., i was surprised that I could tell it:
“Write a Python script that takes an xml file with key and value nodes (I gave it a sample) and given a DynamoDB table with key and value fields, if the key from the XML file has a corresponding key in the DDB table, replace the value node in the XML file with the value field in the DDB table”.
The code worked perfectly.
There is no reason that properly trained model couldn’t create a GUI.
I've recently had the idea that the real problem isn't ease of use and effectivity of these tools, but rather that people who don't code just aren't too interested in developing things. After all, if they were, they'd probably also be interested in learning to code. So I'm not too sold on the idea that these kind of tools will one day make developers go out of business.